RFR: 8291555: Implement alternative fast-locking scheme [v78]

[Roman Kennke]

On Fri, 5 May 2023 17:19:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Slowdebug had a better stack trace:
> 
> 
> 
> ---------------  T H R E A D  ---------------
> 
> 
> 
> Current thread (0x00007fe4ad0062d0):  WorkerThread "GC Thread#0"    [id=19715, stack(0x0000700004416000,0x0000700004516000) (1024K)]
> 
> 
> 
> Stack: [0x0000700004416000,0x0000700004516000],  sp=0x00007000045152b0,  free space=1020k
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> 
> V  [libjvm.dylib+0x133a8a6]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x906  (javaThread.hpp:983)
> 
> V  [libjvm.dylib+0x133af59]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x89
> 
> V  [libjvm.dylib+0x6d4e5c]  report_vm_error(char const*, int, char const*, char const*, ...)+0x1ac
> 
> V  [libjvm.dylib+0xd33f]  JavaThread::cast(Thread*)+0x4f
> 
> V  [libjvm.dylib+0x111911]  JavaThread::current()+0x11
> 
> V  [libjvm.dylib+0xdeffe9]  LockStack::is_owning_thread() const+0x19
> 
> V  [libjvm.dylib+0xdefe14]  LockStack::verify(char const*) const+0x134
> 
> V  [libjvm.dylib+0xac9367]  LockStack::oops_do(OopClosure*)+0x27
> 
> V  [libjvm.dylib+0xac92da]  JavaThread::oops_do_no_frames(OopClosure*, CodeBlobClosure*)+0x2da
> 
> V  [libjvm.dylib+0x1287210]  Thread::oops_do(OopClosure*, CodeBlobClosure*)+0x40
> 
> V  [libjvm.dylib+0x129f395]  ParallelOopsDoThreadClosure::do_thread(Thread*)+0x25
> 
> V  [libjvm.dylib+0x129b6cc]  Threads::possibly_parallel_threads_do(bool, ThreadClosure*)+0xfc
> 
> V  [libjvm.dylib+0x129dfad]  Threads::possibly_parallel_oops_do(bool, OopClosure*, CodeBlobClosure*)+0x3d
> 
> V  [libjvm.dylib+0x99b3b6]  G1RootProcessor::process_java_roots(G1RootClosures*, G1GCPhaseTimes*, unsigned int)+0xc6
> 
> V  [libjvm.dylib+0x99b217]  G1RootProcessor::evacuate_roots(G1ParScanThreadState*, unsigned int)+0x77
> 
> V  [libjvm.dylib+0x9ac68e]  G1EvacuateRegionsTask::scan_roots(G1ParScanThreadState*, unsigned int)+0x2e
> 
> V  [libjvm.dylib+0x9ac568]  G1EvacuateRegionsBaseTask::work(unsigned int)+0x78
> 
> V  [libjvm.dylib+0x13f75b4]  WorkerTaskDispatcher::worker_run_task()+0x74
> 
> V  [libjvm.dylib+0x13f7c14]  WorkerThread::run()+0x34
> 
> V  [libjvm.dylib+0x12868ee]  Thread::call_run()+0x15e
> 
> V  [libjvm.dylib+0xfeafa7]  thread_native_entry(Thread*)+0x117
> 
> C  [libsystem_pthread.dylib+0x68fc]  _pthread_start+0xe0
> 
> C  [libsystem_pthread.dylib+0x2443]  thread_start+0xf
> 
> JavaThread 0x00007fe4af015610 (nid = 22019) was being processed
> 
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> 
> j  java.lang.ref.Reference.waitForReferencePendingList()V+0 java.base
> 
> j  java.lang.ref.Reference.processPendingReferences()V+0 java.base
> 
> j  java.lang.ref.Reference$ReferenceHandler.run()V+8 java.base
> 
> v  ~StubRoutines::call_stub 0x000000011fd08d21
> 
> 
> 
> Does that still match up with your theory?

Yes, definitely. Thanks for trying with slowdebug for confirmation!

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

PR Comment: https://git.openjdk.org/jdk/pull/10907#issuecomment-1536567480