Currently, when we are inside an upcall and hit a safe point, and the GC tries to walk the stack backwards, when jumping from the entry frame to the last Java frame (which contains an intrinsified native call), and if that frame is C2 compiled as well; the GC will try to find oops that are passed as arguments to the enclosing method using a RegisterMap, and that RegisterMap does not contain entries for the arguments, either because it was not updated correctly, or because oop maps are incorrect for an intrinsified native calls.

This will result in a null dereference, giving a stack trace like:

Stack: [0x0000003960400000,0x0000003960500000], sp=0x00000039604fe320, free space=1016k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x2e282a] G1ParCopyClosure<0,0>::do_oop+0xa (g1OopClosures.hpp:172)
V [jvm.dll+0x29394c] frame::oops_compiled_arguments_do+0x1ac (frame.cpp:980)
V [jvm.dll+0x200934] CompiledMethod::preserve_callee_argument_oops+0x2f4 (compiledMethod.cpp:374)
V [jvm.dll+0x293ab2] frame::oops_do_internal+0xc2 (frame.cpp:1053)
V [jvm.dll+0x793e87] JavaThread::oops_do+0x1a7 (thread.cpp:3001)
V [jvm.dll+0x7942c0] Threads::possibly_parallel_oops_do+0x90 (thread.cpp:4675)
V [jvm.dll+0x2e2efc] G1RootProcessor::process_java_roots+0x6c (g1RootProcessor.cpp:169)
V [jvm.dll+0x2e2d68] G1RootProcessor::evacuate_roots+0x68 (g1RootProcessor.cpp:63)
V [jvm.dll+0x2aa9e4] G1EvacuateRegionsTask::scan_roots+0x24 (g1CollectedHeap.cpp:3808)
V [jvm.dll+0x2ac8fb] G1EvacuateRegionsBaseTask::work+0x9b (g1CollectedHeap.cpp:3796)
V [jvm.dll+0x803260] GangWorker::loop+0x50 (workgroup.cpp:349)
V [jvm.dll+0x78f14a] Thread::call_run+0x8a (thread.cpp:403)
V [jvm.dll+0x62eb16] thread_native_entry+0xd6 (os_windows.cpp:463)
C [ucrtbase.dll+0x20e82]
C [KERNEL32.DLL+0x17bd4]
C [ntdll.dll+0x6ce51]

(When using G1)