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/f95f7f4a1163a5f62bdcac16199207ed736fd... and the nmethod entry barrier path that the Java thread executes can be found here: https://github.com/openjdk/jdk17u/blob/f95f7f4a1163a5f62bdcac16199207ed736fd... 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/f95f7f4a1163a5f62bdcac16199207ed736fd...) Cheers, StefanK
Thanks, Florian