FFM upcall stubs embed a Method* of the target method in the stub. This Method* is read from the LambdaForm::vmentry field associated with the target MethodHandle at the time when the upcall stub is generated. The MH instance itself is stashed in a global JNI ref. So, there should be a reachability chain to the holder class: MH (receiver) -> LF (form) -> MemberName (vmentry) -> ResolvedMethodName (method) -> Class<?> (vmholder).

However, it appears that, due to multiple threads racing to initialize the vmentry field of the LambdaForm of the target method handle of an upcall stub, it is possible that the vmentry is updated _after_ we embed the corresponding Method* into an upcall stub. Technically, it is fine to keep using a 'stale' vmentry, but the problem is that now the reachability chain is broken, since the upcall stub only extracts the target Method*, and doesn't keep the stale vmentry reachable. The holder class can then be unloaded, resulting in a crash.