RFR: 8288971: AArch64: Clean up stack and register handling in interpreter [v4]

[Alan Bateman]

On Thu, 30 Jun 2022 15:14:29 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> There are several places in the interpreter that could be improved.
>> 
>> 1. We use r13 to pass the caller's SP to a callee through adapters. r13 is not a callee-saved register in the native ABI, so this causes some complications. Use a callee-saved register.
>> 2. We frequently recalculate the location where the native SP needs to go. We have a spare slot in the interpreter frame, so we should calculate it once, when the frame is created, and use it.
>> 3. Related to 1, we should clearly label all the places where the caller's SP is passed to a callee.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update templateInterpreterGenerator_aarch64.cpp

Most of the JVM TI tests for virtual threads are now failing on aarch64, they are hitting this assert


#  Internal Error (/workspace/open/src/hotspot/share/runtime/thread.hpp:480), pid=1448788, tid=1448821
#  assert(stack_base() > limit && limit >= stack_end()) failed: limit is outside of stack

:

V  [libjvm.so+0x17b1af0]  StackOverflow::enable_stack_reserved_zone(bool)+0x5c
V  [libjvm.so+0x174b688]  SharedRuntime::enable_stack_reserved_zone(JavaThread*)+0x44
j  jdk.internal.vm.Continuation.onContinue()V+0 java.base at 20-ea
j  jdk.internal.vm.Continuation.yield0(Ljdk/internal/vm/ContinuationScope;Ljdk/internal/vm/Continuation;)Z+317 java.base at 20-ea
j  jdk.internal.vm.Continuation.yield(Ljdk/internal/vm/ContinuationScope;)Z+69 java.base at 20-ea
J 310 c1 java.lang.VirtualThread.yieldContinuation()Z java.base at 20-ea (55 bytes) @ 0x0000ffff9d0503b8 [0x0000ffff9d050200+0x00000000000001b8]
J 155  jdk.internal.vm.Continuation.enterSpecial(Ljdk/internal/vm/Continuation;ZZ)V java.base at 20-ea (0 bytes) @ 0x0000ffffa4aaf738 [0x0000ffffa4aaf6c0+0x0000000000000078]
J 326 c1 jdk.internal.vm.Continuation.run()V java.base at 20-ea (586 bytes) @ 0x0000ffff9d05f8e8 [0x0000ffff9d05f040+0x00000000000008a8]
J 324 c1 java.lang.VirtualThread.runContinuation()V java.base at 20-ea (135 bytes) @ 0x0000ffff9d05daf8 [0x0000ffff9d05d5c0+0x0000000000000538]
J 323 c1 java.lang.VirtualThread$$Lambda$8+0x000000080104b138.run()V java.base at 20-ea (8 bytes) @ 0x0000ffff9d05d07c [0x0000ffff9d05cf80+0x00000000000000fc]
J 321 c1 java.util.concurrent.ForkJoinTask.doExec()I java.base at 20-ea (37 bytes) @ 0x0000ffff9d05b094 [0x0000ffff9d05ae80+0x0000000000000214]
J 299 c1 java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(Ljava/util/concurrent/ForkJoinTask;Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V java.base at 20-ea (83 bytes) @ 0x0000ffff9d046f0c [0x0000ffff9d046dc0+0x000000000000014c]
J 214 c1 java.util.concurrent.ForkJoinPool.scan(Ljava/util/concurrent/ForkJoinPool$WorkQueue;II)I java.base at 20-ea (250 bytes) @ 0x0000ffff9d01beac [0x0000ffff9d01b840+0x000000000000066c]
j  java.util.concurrent.ForkJoinPool.runWorker(Ljava/util/concurrent/ForkJoinPool$WorkQueue;)V+35 java.base at 20-ea
j  java.util.concurrent.ForkJoinWorkerThread.run()V+31 java.base at 20-ea
v  ~StubRoutines::call_stub 0x0000ffffa45001bc
V  [libjvm.so+0xf8242c]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x5ac
V  [libjvm.so+0xf82a88]  JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0x3e8
V  [libjvm.so+0xf82e04]  JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)+0x70
V  [libjvm.so+0x10fbdb8]  thread_entry(JavaThread*, JavaThread*)+0x118
V  [libjvm.so+0xfb8bf4]  JavaThread::thread_main_inner()+0x250
V  [libjvm.so+0x18d0ac8]  Thread::call_run()+0xf8
V  [libjvm.so+0x15db2e4]  thread_native_entry(Thread*)+0x104
C  [libpthread.so.0+0x78f8]  start_thread+0x188

-------------

PR: https://git.openjdk.org/jdk/pull/9239