Question about backporting JDK-8223923 : C2: Missing interference with mismatched unsafe accesses

[gaoxiang at kylinos.cn]

Hello,

 

I have a question about the backporting of JDK-8223923, specifically whether
it is applicable to our situation:

 

It is similar to JDK-8212637, We got a report from our customer that C2
thread got 100% CPU usage. Due to their security policies in the production
environment, we are unable to get more details using gdb or JIT debugging
information. The probability of this issue recurring is very low, having
occurred only twice in the past two months. (The customer did not preserve
the scene...)

 

>From the flame graph, we noticed the "while" loop in can_see_stored_value
caused CPU usage, and the critical path was MemBarCPUOrder. We found a patch
in JDK-8223923, which forbids stepping over MemBarCPUOrder nodes in
can_see_stored_value . With this fix, the conditions for the customer's
issue to recur no longer exist. 

 

Perf record:

Samples: 10K of event 'cycles:ppp', Event count (approx.): 26570671846


  Children      Self  Command          Shared Object       Symbol


-   98.18%     0.00%  C2 CompilerThre  libjvm.so           [.]
Compile::Compile                          

     Compile::Compile


     Compile::Optimize


     PhaseIterGVN::optimize


     PhaseIterGVN::transform_old


     LoadNode::Value


   - MemNode::can_see_stored_value


      + 35.08% MergeMemNode::memory_at


        13.03% MemBarCPUOrderNode::Opcode


        8.97% Node::in (inlined)


      + 1.97% MergeMemNode::base_memory (inlined)


+   98.18%     0.00%  C2 CompilerThre  libjvm.so           [.]
Compile::Optimize                         

+   98.18%     0.00%  C2 CompilerThre  libjvm.so           [.]
PhaseIterGVN::optimize                    

+   98.18%     0.00%  C2 CompilerThre  libjvm.so           [.]
PhaseIterGVN::transform_old               

+   98.18%     0.00%  C2 CompilerThre  libjvm.so           [.]
LoadNode::Value                           

+   98.18%    50.06%  C2 CompilerThre  libjvm.so           [.]
MemNode::can_see_stored_value             

+   35.08%    26.14%  C2 CompilerThre  libjvm.so           [.]
MergeMemNode::memory_at                   

+   17.58%     0.00%  C2 CompilerThre  libjvm.so           [.] Node::in
(inlined)                        

+   14.14%     0.00%  C2 CompilerThre  libjvm.so           [.]
MergeMemNode::base_memory (inlined)       

+   13.03%    13.00%  C2 CompilerThre  libjvm.so           [.]
MemBarCPUOrderNode::Opcode                

+   10.94%     0.00%  C2 CompilerThre  libjvm.so           [.] Node::in
(inlined)                        

+    9.58%     0.00%  C2 CompilerThre  libjvm.so           [.]
Compile::current (inlined)                

+    9.58%     0.00%  C2 CompilerThre  libjvm.so           [.]
ciEnv::current (inlined)                  

+    9.58%     0.00%  C2 CompilerThre  libjvm.so           [.]
CompilerThread::current (inlined)         

+    9.58%     0.00%  C2 CompilerThre  libjvm.so           [.]
JavaThread::current (inlined)             

+    9.58%     0.00%  C2 CompilerThre  libjvm.so           [.]
Thread::current (inlined)                 

+    9.58%     0.00%  C2 CompilerThre  libjvm.so           [.]
Thread::current_or_null (inlined)         

+    8.94%     8.94%  C2 CompilerThre  libjvm.so           [.]
ThreadLocalStorage::is_initialized        

+    8.94%     0.00%  C2 CompilerThre  libjvm.so           [.]
ThreadLocalStorage::thread_index (inlined)

+    1.97%     0.00%  C2 CompilerThre  libjvm.so           [.]
MergeMemNode::base_memory (inlined)       

     0.08%     0.08%  RxComputationSc  perf-1012711.map    [.]
0x0000fffcb00122c8                        

     0.06%     0.06%  RxComputationSc  perf-1012711.map    [.]
0x0000fffcb0012444                        

     0.06%     0.06%  RxComputationSc  perf-1012711.map    [.]
0x0000fffcb0023620   

 

JDK-8223923 has already been merged into JDK11&17. Based on the frequency of
the issue, we are not yet able to verify the modification.

Could we get a suggestion about whether this patch should be backported to
JDK 8?

 

Thanks~

BR

Mail: gaoxiang at kylinos.cn <mailto:gaoxiang at kylinos.cn> 

Tel: 13502020281

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk8u-dev/attachments/20240428/2851daa8/attachment-0001.htm>