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

[Stefan Karlsson]

Hi,

Thanks for reporting this. This most likely triggers in the GC's 
handling of object pointers (oops) inside JIT:ed methods (nmethods). 
These are the only pointers that can be misaligned. Typically, we write 
to these locations without a CAS (code from > JDK 21):
```

// Non-atomic healing helps speed up root scanning. This is safe to do

// since we are always healing roots in a safepoint, or under a lock,

// which ensures we are never racing with mutators modifying roots while

// we are healing them. It's also safe in case multiple GC threads try

// to heal the same root if it is aligned, since they would always heal

// the root in the same way and it does not matter in which order it

// happens. For misalignedoops, there needs to be mutual exclusion.

*p = XOop::from_address(good_addr);

```

We do use locks to ensure that only one thread writes to these pointers 
in the JIT:ed methods.

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.

FWIW, the ZGC code in JDK 17 is the non-generational version of ZGC. In 
JDK 21 we introduced Generational ZGC, and in that version we have 
removed the CAS:es in the root processing of JIT:ed methods. Cheers, 
StefanK

On 2024-09-10 14:20, jianping Lu wrote:
> HI ALL:
>
> When running JDK 17.0.2 on a Linux x86_64 architecture with ZGC and 
> the JVM option -XX:-ClassUnloading, I encounter split lock warnings 
> from the Linux kernel. This issue appears consistently during garbage 
> collection operations.
>
> Here is the specific warning message from the kernel:
>     x86/split lock detection: #AC: ZWorker#0/2154775 took a split_lock 
> trap at address:     0x7f50c6e0433c
>
> Upon investigating the assembly at this address, I identified the 
> following instruction:
>    0x00007f50c6e0433c <+76>: lock cmpxchg %rcx,(%rbx)
>
> This is part of the function:
>     Dump of assembler code for function 
> _ZN15ZMarkOopClosure6do_oopEPP7oopDesc:
>  0x00007f50c6e0433c <+76>: lock cmpxchg %rcx,(%rbx)
>
> The split lock warning occurs during the execution of the ZWorker 
> thread, which is responsible for concurrent marking in ZGC. The 
> warning seems to be triggered specifically when class unloading is 
> disabled with -XX:-ClassUnloading.
>
> Environment:
> JDK Version: OpenJDK 17.0.2
> GC: ZGC with -XX:-ClassUnloading
> OS: Linux x86_64
>
>  I would like to understand if this behavior is expected when class 
> unloading is disabled or if there are any recommended fixes or 
> workarounds for avoiding the split lock issue during concurrent 
> garbage collection.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/zgc-dev/attachments/20240911/8ef9d065/attachment.htm>