<div class="__aliyun_email_body_block"><div  style="line-height:1.7;font-family:Microsoft Yahei;font-size:14.0px;color:#000000;"><div  style="clear:both;"><span >Hi @dean-long,</span><div  style="clear:both;"><br ></div><div  style="clear:both;">I tried, and it works.</div><div  style="clear:both;"><br ></div><div  style="clear:both;">Another way is to skip the processing of MachTemp when building the oop map. Do you think this is the correct way?</div><div  style="clear:both;"><br ></div><span >Denghui Dong</span></div><div  style="clear:both;"><br /></div><blockquote  style="margin-right:0;margin-top:0;margin-bottom:0;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><div  style="clear:both;">------------------------------------------------------------------</div><div  style="clear:both;">From:dean.long <dean.long@oracle.com></div><div  style="clear:both;">Send Time:2022年7月22日(星期五) 11:28</div><div  style="clear:both;">To:undefined <undefined>; undefined <undefined></div><div  style="clear:both;">Subject:Re: Crash due to bad oop map</div><div  style="clear:both;"><br /></div>Hi Denghui Dong.  This looks like JDK-8051805 <br >(https://bugs.openjdk.org/browse/JDK-8051805).  As you discovered, it is <br >triggered when RegN is used as a TEMP.  As a work-around, have you tried <br >using rRegI instead of rRegN for your TEMPs?<br ><br >dl<br ><br >On 7/21/22 12:11 AM, Denghui Dong wrote:<br >> Hi team,<br >> <br >> We encountered a crash due to a bad oop map.<br >> The following steps can quickly reproduce the problem on JDK master on <br >> Linux x64:<br >> 1. Modify z_x86_64.ad and add 3 temporary registers of type rRegN to <br >> zLoadP(If this change is illegal, please let me know)<br >> ```<br >> diff --git a/src/hotspot/cpu/x86/gc/z/z_x86_64.ad <br >> b/src/hotspot/cpu/x86/gc/z/z_x86_64.ad<br >> index f3e19b41733..129c93d3da8 100644<br >> --- a/src/hotspot/cpu/x86/gc/z/z_x86_64.ad<br >> +++ b/src/hotspot/cpu/x86/gc/z/z_x86_64.ad<br >> @@ -63,11 +63,11 @@ static void z_load_barrier_cmpxchg(MacroAssembler& <br >> _masm, const MachNode* node,<br >> %}<br >> // Load Pointer<br >> -instruct zLoadP(rRegP dst, memory mem, rFlagsReg cr)<br >> +instruct zLoadP(rRegP dst, memory mem, rRegN tmp1, rRegN tmp2, rRegN <br >> tmp3, rFlagsReg cr)<br >> %{<br >>    predicate(UseZGC && n->as_Load()->barrier_data() != 0);<br >>    match(Set dst (LoadP mem));<br >> -  effect(KILL cr, TEMP dst);<br >> +  effect(KILL cr, TEMP dst, TEMP tmp1, TEMP tmp2, TEMP tmp3);<br >>    ins_cost(125);<br >> ```<br >> 2. Run the following code <br >> (./build/linux-x86_64-server-fastdebug/images/jdk/bin/java -XX:-Inline <br >> -XX:CompileCommand=compileonly,Test::call -XX:+PrintAssembly <br >> -XX:PrintIdealGraphLevel=2 -XX:PrintIdealGraphFile=call.xml -XX:+UseZGC <br >> -XX:+UseNewCode -XX:+PrintGC -Xmx500m -Xms500m -XX:-Inline Test)<br >> ```<br >> import java.util.concurrent.locks.Lock;<br >> import java.util.concurrent.locks.ReentrantLock;<br >> class Test {<br >>    private Lock lock = new ReentrantLock();<br >>    public static void main(String... args) throws Exception {<br >>      new Thread(() -> {<br >>        while (true) {<br >>          byte[] b = new byte[10 * 1024 * 1024];<br >>        }<br >>      }).start();<br >>      while (true) {<br >>        new Test().call(() -> { new Object(); });<br >>      }<br >>    }<br >>    public void call(Runnable cb) {<br >>      lock.lock();<br >>      try {<br >>        cb.run();<br >>      } finally {<br >>        lock.unlock();<br >>      }<br >>    }<br >> }<br >> ```<br >> <br >> It can be observed through the IGV Final Code that zLoadP(202, 204) and <br >> a MachTemp(81) it uses are placed in different blocks. When processing <br >> CallStaticJavaDirect(74) in the c2 buildOopMap step, MachTemp(81) is <br >> considered to be alive. Because the register type specified by the above <br >> modification is rRegN (if it is specified as rRegI or rRegP, no crash <br >> will occur), so the type of MachTemp(81) is narrowOop, which will <br >> eventually be added to the oopMap of CallStaticJavaDirect(74). But <br >> logically, zLoadP doesn't depend on the original value of MachTemp(81), <br >> so I don't think it should be added to oopMap.<br >> <br >> I put the ideal graph file to http://cr.openjdk.java.net/~ddong/call.xml <br >> <http://cr.openjdk.java.net/~ddong/call.xml><br >> <br >> I think the problem may lie in two places:<br >> 1. gcm and regAlloc do not put MachTemp(81) in the correct location<br >> 2. buildOopMap should not treat MachTemp as Oop because its original <br >> value is meaningless<br >> <br >> I'm not a JIT expert and sorry if there is anything unnatural or <br >> non-standard in the above description.<br >> <br >> Any input is appreciated.<br >> <br >> Denghui Dong</blockquote></div></div>