Split Lock Warning with ZGC and -XX:-ClassUnloading on Linux x86_64, JDK 17.0.2

[Stefan Karlsson]

On 2024-09-11 12:34, Florian Weimer wrote:
> * Stefan Karlsson:
>
>> However, when class unloading is turned off we consider the object
>> pointers in the JIT:ed methods to be roots into the object graph. When
>> we walk these specific roots we take another path than the one pasted
>> above, and that path performs a CAS to fix the pointers. It is still
>> guarded by a lock, so there is is still mutual exclusion on this
>> field. So, if I understand things correctly, there's no known problem
>> with this because of the mutual exclusion, except that the split lock
>> detector reports an issue.
> Wouldn't the nmethod experience tearing during execution because it
> doesn't take the lock?

The executing thread uses the same lock to stabilize the oops before the 
execution can continue. This is referred to as the "nmethod entry barrier".

If you want to follow the code more closely, you can see the GC root 
processing path here:
https://github.com/openjdk/jdk17u/blob/f95f7f4a1163a5f62bdcac16199207ed736fdc15/src/hotspot/share/gc/z/zMark.cpp#L639

and the nmethod entry barrier path that the Java thread executes can be 
found here:
https://github.com/openjdk/jdk17u/blob/f95f7f4a1163a5f62bdcac16199207ed736fdc15/src/hotspot/share/gc/z/zBarrierSetNMethod.cpp#L34

Note that the Java threads call the nmethod entry barrier for two reasons:
1) When it calls into an nmethod
2) When it got blocked in a safepoint and ZGC switched phase to either 
start marking or start relocation. When it wakes up again, all the oops 
needs to be stabilized and the nmethod entry barrier code is rerun. (See 
https://github.com/openjdk/jdk17u/blob/f95f7f4a1163a5f62bdcac16199207ed736fdc15/src/hotspot/share/gc/z/zStackWatermark.cpp#L39)

Cheers,
StefanK


>
> Thanks,
> Florian
>