<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
Hi,<br>
<br>
Thanks for reporting this. This most likely triggers in the GC's
handling of object pointers (oops) inside <a class="moz-txt-link-freetext" href="JIT:ed">JIT:ed</a> methods (nmethods).
These are the only pointers that can be misaligned. Typically, we
write to these locations without a CAS (code from > JDK 21):<br>
```<br>
<div style="background-color:#fcfcfc;padding:0px 0px 0px 2px;">
<div style="color:#212121;background-color:#fcfcfc;font-family:"Monospace";font-size:10pt;white-space:pre;"><p style="margin:0;"><span style="color:#000000;"> </span><span style="color:#3f7f5f;">// Non-atomic healing helps speed up root scanning. This is safe to do</span></p><p style="margin:0;"><span style="color:#000000;"> </span><span style="color:#3f7f5f;">// since we are always healing roots in a </span><span style="color:#3f7f5f;text-decoration:underline;text-decoration-color:#ff8040;text-decoration-style:wavy;">safepoint</span><span style="color:#3f7f5f;">, or under a lock,</span></p><p style="margin:0;"><span style="color:#000000;"> </span><span style="color:#3f7f5f;">// which ensures we are never racing with mutators modifying roots while</span></p><p style="margin:0;"><span style="color:#000000;"> </span><span style="color:#3f7f5f;">// we are healing them. It's also safe in case multiple GC threads try</span></p><p style="margin:0;"><span style="color:#000000;"> </span><span style="color:#3f7f5f;">// to heal the same root if it is aligned, since they would always heal</span></p><p style="margin:0;"><span style="color:#000000;"> </span><span style="color:#3f7f5f;">// the root in the same way and it does not matter in which order it</span></p><p style="margin:0;"><span style="color:#000000;"> </span><span style="color:#3f7f5f;">// happens. For </span><span style="color:#3f7f5f;text-decoration:underline;text-decoration-color:#ff8040;text-decoration-style:wavy;">misaligned</span><span style="color:#3f7f5f;"> oops, there needs to be mutual exclusion.</span></p><p style="margin:0;"><span style="color:#000000;"> *p = </span><span style="color:#005032;">XOop</span><span style="color:#000000;">::</span><span style="color:#000000;font-style:italic;">from_address</span><span style="color:#000000;">(good_addr);</span></p><p style="margin:0;"><span style="color:#000000;">```</span></p><p style="margin:0;"><span style="color:#000000;">
</span></p><p style="margin:0;"><span style="color:#000000;">We do use locks to ensure that only one thread writes to these pointers in the <a class="moz-txt-link-freetext" href="JIT:ed">JIT:ed</a> methods.</span></p><p style="margin:0;"><span style="color:#000000;">
</span></p><p style="margin:0;"><span style="color:#000000;">However, when class unloading is turned off we consider the object pointers in the <a class="moz-txt-link-freetext" href="JIT:ed">JIT:ed</a> 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.</span></p>
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 <a class="moz-txt-link-freetext" href="CAS:es">CAS:es</a> in the root processing of <a class="moz-txt-link-freetext" href="JIT:ed">JIT:ed</a> methods.
Cheers,
StefanK
</div>
</div>
<br>
<div class="moz-cite-prefix">On 2024-09-10 14:20, jianping Lu wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAOXKhpWKi-jVR6n3sWyrkLxe95e=nUYPBJuQV=wL62WGMNXSSA@mail.gmail.com">
<div dir="ltr">HI ALL:<br>
<br>
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.<br>
<br>
Here is the specific warning message from the kernel:<br>
x86/split lock detection: #AC: ZWorker#0/2154775 took a
split_lock trap at address: 0x7f50c6e0433c<br>
<br>
Upon investigating the assembly at this address, I identified
the following instruction:<br>
0x00007f50c6e0433c <+76>: lock cmpxchg %rcx,(%rbx)<br>
<br>
This is part of the function:<br>
Dump of assembler code for function
_ZN15ZMarkOopClosure6do_oopEPP7oopDesc:<br>
0x00007f50c6e0433c <+76>: lock cmpxchg %rcx,(%rbx)<br>
<br>
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.<br>
<br>
Environment:<br>
JDK Version: OpenJDK 17.0.2<br>
GC: ZGC with -XX:-ClassUnloading<br>
OS: Linux x86_64
<div><br>
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.</div>
</div>
</blockquote>
<br>
</body>
</html>