
<div class="__aliyun_email_body_block"><div  style="line-height:1.7;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><div  style="clear:both;">Hi Vladimir,</div><div  style="clear:both;"><br ></div><div  style="clear:both;">Thank you for the information. RVC's performance gain is a side effect alike thing, and it seems the larger the icache size, the less performance gain of it. Besides, the current RVC implement in the backend is only a basic one, covering some of C2 match rules, far from complete. So I might not assume observing performance gain with the current RVC implementation, but we should also not observe regressions of generated code here. So of course I'd agree with your analysis.</div><div  style="clear:both;"><br ></div><div  style="clear:both;"><span >The second one seems interesting as well. Weird, it seems a common native out of memory, so shouldn't turning off RVC reveal the same issue, I guess? I will wait for the JBS issue and do some JVM options tuning to simulate that case to see if I can reproduce it in the meantime.</span></div><div  style="clear:both;"><span ><br ></span></div><div  style="clear:both;"><span >Best,</span></div><div  style="clear:both;"><span >Xiaolin</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:Vladimir Kempik <vladimir.kempik@gmail.com></div><div  style="clear:both;">Send Time:2022年9月15日(星期四) 20:33</div><div  style="clear:both;">To:郑孝林(云矅) <yunyao.zxl@alibaba-inc.com></div><div  style="clear:both;">Cc:riscv-port-dev <riscv-port-dev-retn@openjdk.org>; Aleksey Shipilev <shade@redhat.com>; riscv-port-dev@openjdk.org <riscv-port-dev@openjdk.org></div><div  style="clear:both;">Subject:Re: RVC by default?</div><div  style="clear:both;"><br /></div><head ></head>Hello<div  class="">Yes, it’s slightly unstable. even on fpga.</div><div  class="">I have found I can compare results only from two consequential runs ( e.g. first run without RVC, second run with RVC), then some average result from iterations 5-15, removing some too slow results.</div><div  class="">I think your results shows no perf gain from RVC, that’s expected as RVC gives no perf improvements for opcodes, only requiring less i-cache space.</div><div  class=""><br  class=""></div><div  class="">Another interesting moment with RVC, I see some jdk failure only when RVC is enabled and only on fpga. ( on philosophers test)</div><div  class="">it’s very strange, I will try to debug it and file a bug in JBS if it turns out to be a real jdk bug (or this could easily be a fpga "core" issue)</div><div  class=""><br  class=""></div><div  class="">Regards, Vladimir</div><div  class=""><br  class=""></div><div  class=""><div  class="" style="margin:.0px;font-stretch:normal;font-size:11.0px;line-height:normal;font-family:Menlo;"><span  class="" style="font-variant-ligatures:no-common-ligatures;"># Native memory allocation (malloc) failed to allocate 4352974235792 bytes for Chunk::new</span></div><div  class=""><span  class="" style="font-variant-ligatures:no-common-ligatures;"><div  class="" style="margin:.0px;font-stretch:normal;font-size:11.0px;line-height:normal;font-family:Menlo;"><span  class="" style="font-variant-ligatures:no-common-ligatures;">#  Out of Memory Error (arena.cpp:184), pid=5722, tid=5723</span></div><div  class=""><span  class="" style="font-variant-ligatures:no-common-ligatures;"><div  class="">Stack: [0x0000003f83111000,0x0000003f83311000],  sp=0x0000003f8330e2e0,  free space=2036k</div><div  class="">Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)</div><div  class="">V  [libjvm.so+0xa6c064]  VMError::report_and_die(int, char const*, char const*, void*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x16a</div><div  class="">V  [libjvm.so+0xa6ca9e]  VMError::report_and_die(Thread*, char const*, int, unsigned long, VMErrorType, char const*, void*)+0x28</div><div  class="">V  [libjvm.so+0x3ff306]  report_vm_out_of_memory(char const*, int, unsigned long, VMErrorType, char const*, ...)+0x6a</div><div  class="">V  [libjvm.so+0x2603de]  Chunk::operator new(unsigned long, AllocFailStrategy::AllocFailEnum, unsigned long)+0x108</div><div  class="">V  [libjvm.so+0x260cf2]  Arena::grow(unsigned long, AllocFailStrategy::AllocFailEnum)+0x36</div><div  class="">V  [libjvm.so+0x8d7392]  AdapterHandlerLibrary::create_adapter(AdapterBlob*&, int, BasicType*, bool)+0x39e</div><div  class="">V  [libjvm.so+0x8dcb7e]  AdapterHandlerLibrary::get_adapter(methodHandle const&)+0x41e</div><div  class="">J 5 c1 java.util.ImmutableCollections$SetN.probe(Ljava/lang/Object;)I java.base (56 bytes) @ 0x0000003f696e5858 [0x0000003f696e5700+0x0000000000000158]</div><div  class="">j  java.util.ImmutableCollections$SetN.<init>([Ljava/lang/Object;)V+35 java.base</div><div  class="">j  java.util.Set.of([Ljava/lang/Object;)Ljava/util/Set;+64 java.base</div><div  class="">j  jdk.internal.module.SystemModules$default.moduleDescriptors()[Ljava/lang/module/ModuleDescriptor;+3619 java.base</div><div  class="">j  jdk.internal.module.SystemModuleFinders.of(Ljdk/internal/module/SystemModules;)Ljava/lang/module/ModuleFinder;+1 java.base</div><div  class="">j  jdk.internal.module.ModuleBootstrap.boot2()Ljava/lang/ModuleLayer;+240 java.base</div><div  class="">j  jdk.internal.module.ModuleBootstrap.boot()Ljava/lang/ModuleLayer;+64 java.base</div><div  class="">j  java.lang.System.initPhase2(ZZ)I+0 java.base</div><div  class="">v  ~StubRoutines::call_stub 0x0000003f70c1c49c</div><div  class="">V  [libjvm.so+0x5b790c]  JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)+0x1d6</div><div  class="">V  [libjvm.so+0x5b7b68]  JavaCalls::call_static(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)+0xe8</div><div  class="">V  [libjvm.so+0xa0281c]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x63c</div><div  class="">V  [libjvm.so+0x647656]  JNI_CreateJavaVM+0x6a</div><div  class="">C  [libjli.so+0x3658]  JavaMain+0x7a</div><div  class="">C  [libjli.so+0x670e]  ThreadJavaMain+0xc</div><div  class=""><br  class=""></div></span></div></span></div><div ><br  class=""><div  class="">15 сент. 2022 г., в 06:25, Xiaolin Zheng <<a  class="" href="mailto:yunyao.zxl@alibaba-inc.com" target="_blank">yunyao.zxl@alibaba-inc.com</a>> написал(а):</div><br  class="Apple-interchange-newline"><div  class=""><div  class="" style="line-height:1.7;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;"><div  class="" style="clear:both;">Hi Vladimir,</div><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;"><span  class="">There are some minor updates for the philosophers in Renaissance discussed days before: </span><span  class="">I have tested the philosophers on my Unmatched board, and found the test itself seems not stable, even if the JMH version. I gave its JMH version a two-day long run, exclusively, but the score varies in the 13000 ms/op range (iterations = 30 by default), even if RVC doesn't get turned on. Have you encountered the same issue?</span></div><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;"><span  class="">+ /home/ubuntu/yunyao/jdk19-release/bin/java -XX:+UnlockExperimentalVMOptions -XX:-UseRVC -jar renaissance-jmh-0.14.1.jar org.renaissance.scala.stm.JmhPhilosophers.runOperation</span><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  14307.472 ± 656.456  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13175.640 ± 303.038  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13474.124 ± 349.349  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13545.786 ± 327.735  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13085.097 ± 306.891  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  12880.270 ± 265.028  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13232.006 ± 209.613  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13334.098 ± 443.757  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13168.990 ± 575.965  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13424.250 ± 381.084  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13655.426 ± 428.624  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  14430.485 ± 488.797  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13999.061 ± 359.320  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13623.308 ± 531.513  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13757.331 ± 373.905  ms/op</div><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;">+ /home/ubuntu/yunyao/jdk19-release/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseRVC -jar renaissance-jmh-0.14.1.jar org.renaissance.scala.stm.JmhPhilosophers.runOperation</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  12772.517 ± 227.409  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13456.228 ± 498.724  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13727.211 ± 476.491  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13122.838 ± 246.673  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13082.768 ± 405.194  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13905.753 ± 456.474  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13503.479 ± 351.191  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13365.138 ± 380.285  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13842.509 ± 487.629  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13965.286 ± 330.423  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13615.975 ± 352.590  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13564.777 ± 452.947  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  13720.022 ± 519.965  ms/op</div><div  class="" style="clear:both;">JmhPhilosophers.runOperation    ss   40  14033.287 ± 404.377  ms/op</div><span  class="">JmhPhilosophers.runOperation    ss   40  13680.432 ± 539.549  ms/op</span></div><div  class="" style="clear:both;"><span  class=""><span  class=""><br  class=""></span></span></div><div  class="" style="clear:both;"><span  class=""><span  class="">The noise here is a little big; I was wondering if it's stable on the FPGA?</span></span></div><div  class="" style="clear:both;"><span  class=""><span  class=""><br  class=""></span></span></div><div  class="" style="clear:both;"><span  class="">Maybe I need to find some more stable tests anyway.</span></div><div  class="" style="clear:both;"><span  class=""><br  class=""></span></div><div  class="" style="clear:both;"><span  class=""><br  class=""></span></div><div  class="" style="clear:both;"><span  class=""><br  class=""></span></div><div  class="" style="clear:both;"><span  class="">Best,</span></div><div  class="" style="clear:both;"><span  class="">Xiaolin</span></div><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;">------------------------------------------------------------------</div><div  class="" style="clear:both;">From:Vladimir Kempik <<a  class="" href="mailto:vladimir.kempik@gmail.com" target="_blank">vladimir.kempik@gmail.com</a>></div><div  class="" style="clear:both;">Send Time:2022年9月8日(星期四) 20:24</div><div  class="" style="clear:both;">To:郑孝林(云矅) <<a  class="" href="mailto:yunyao.zxl@alibaba-inc.com" target="_blank">yunyao.zxl@alibaba-inc.com</a>></div><div  class="" style="clear:both;">Cc:riscv-port-dev <<a  class="" href="mailto:riscv-port-dev-retn@openjdk.org" target="_blank">riscv-port-dev-retn@openjdk.org</a>>; Aleksey Shipilev <<a  class="" href="mailto:shade@redhat.com" target="_blank">shade@redhat.com</a>>; <a  class="" href="mailto:riscv-port-dev@openjdk.org" target="_blank">riscv-port-dev@openjdk.org</a> <<a  class="" href="mailto:riscv-port-dev@openjdk.org" target="_blank">riscv-port-dev@openjdk.org</a>></div><div  class="" style="clear:both;">Subject:Re: RVC by default?</div><div  class="" style="clear:both;"><br  class=""></div>Hello<div  class="">To be more specific, I saw slight perf decrease with RVC only on a core running on fpga.</div><div  class="">On thead c910 results ( -RVC and + RVC) are on par.</div><div  class=""><br  class=""></div><div  class="">Regards, Vladimir<br  class=""><div  class=""><br  class=""><div  class="">8 сент. 2022 г., в 15:09, Xiaolin Zheng <<a  class="" href="mailto:yunyao.zxl@alibaba-inc.com" target="_blank">yunyao.zxl@alibaba-inc.com</a>> написал(а):</div><br  class="Apple-interchange-newline"><div  class=""><div  class="" style="line-height:1.7;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;"><div  class="" style="clear:both;"><span  class="">Hi Aleksey and Vladimir,</span></div><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;">The current RVC support is okay but not complete: it only covers ~10% of total instructions emitted (mostly C2 code, including some part of Stub code), and we might want to transform instructions into the compressed counterparts as much as possible, so maybe the design will change from a whitelist mode (the class CompressibleRegion) to a black list mode. There is one implementation at my local branch <a  class="" href="https://github.com/zhengxiaolinX/jdk/commits/REBASE-rvc-beautify" target="_blank">https://github.com/zhengxiaolinX/jdk/commits/REBASE-rvc-beautify</a> (might not be stable yet, I have not gotten enough time to give it a sufficient test on jtregs and specjbb2015/other benchmarks yet). There are plans reserved to commit them (which cover ~20% of instructions under some tests) after reviewing, but this is currently WIP and waiting loom port to merge first.<br  class=""></div><div  class="" style="clear:both;"><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;">And thank you Vladimir for your observations, I will test the Renaissance benchmark as you have mentioned. I have given tests for specjbb2015 months before and found slight performance increase there; as far as I know, the compile time will increase for the transformation logic is extra overhead during the instruction emission phase, such as the code in Assembler::add. Theoretically, when running the compiled code with RVC turning on, though IPC and CPI are not changed, the code size shrinks; I think it should have the same effect as the icache size becoming larger. Maybe something goes wrong? :-) I might need to look into the performance problem in a high priority, so will test the <span  class=" __aliyun_node_has_bgcolor" style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:.0px;text-transform:none;white-space:normal;word-spacing:.0px;background-color:#ffffff;float:none;display:inline;">Renaissance</span> first.</div><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;">Best,</div><span  class="">Xiaolin</span></div><div  class="" style="clear:both;"><br  class=""></div><div  class="" style="clear:both;">------------------------------------------------------------------</div><div  class="" style="clear:both;">From:Aleksey Shipilev <<a  class="" href="mailto:shade@redhat.com" target="_blank">shade@redhat.com</a>></div><div  class="" style="clear:both;">Send Time:2022年9月8日(星期四) 18:34</div><div  class="" style="clear:both;">To:undefined <undefined>; undefined <undefined></div><div  class="" style="clear:both;">Subject:RVC by default?</div><div  class="" style="clear:both;"><br  class=""></div>Hi,<br  class=""><br  class="">I was looking at some generated code on RISC-V, and realized while we have RVC support, we don't <br  class="">enable it by default. On HiFive Unleashed:<br  class=""><br  class="">$ test-jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal 2>&1 | grep RVC<br  class="">      bool UseRVC                                   = false                           {ARCH <br  class="">experimental} {default}<br  class=""><br  class=""><br  class="">Is there a reason not to do RVC by default? Can we reliably poll the RVC capabilities in current <br  class="">hardware?<br  class=""><br  class="">-- <br  class="">Thanks,<br  class="">-Aleksey</div></div></div><br  class=""></div></div></div></div><br  class=""></div></blockquote></div></div>