On Fri, 5 May 2023 17:19:11 GMT, Daniel D. Daugherty <dcu...@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
