RFR: 8291555: Implement alternative fast-locking scheme [v78]
Roman Kennke
rkennke at openjdk.org
Fri May 5 17:35:32 UTC 2023
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
More information about the serviceability-dev
mailing list