<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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 style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""># Native memory allocation (malloc) failed to allocate 4352974235792 bytes for Chunk::new</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""># Out of Memory Error (arena.cpp:184), pid=5722, tid=5723</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><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=""><blockquote type="cite" class=""><div class="">15 сент. 2022 г., в 06:25, Xiaolin Zheng <<a href="mailto:yunyao.zxl@alibaba-inc.com" class="">yunyao.zxl@alibaba-inc.com</a>> написал(а):</div><br class="Apple-interchange-newline"><div class=""><div class="__aliyun_email_body_block"><div style="line-height: 1.7; font-family: Tahoma, Arial, STHeiti, SimSun; font-size: 14px;" class=""><div style="clear:both;" class="">Hi Vladimir,</div><div style="clear:both;" class=""><br class=""></div><div style="clear:both;" class=""><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 style="clear:both;" class=""><br class=""></div><div style="clear:both;" class=""><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 style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 14307.472 ± 656.456 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13175.640 ± 303.038 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13474.124 ± 349.349 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13545.786 ± 327.735 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13085.097 ± 306.891 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 12880.270 ± 265.028 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13232.006 ± 209.613 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13334.098 ± 443.757 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13168.990 ± 575.965 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13424.250 ± 381.084 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13655.426 ± 428.624 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 14430.485 ± 488.797 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13999.061 ± 359.320 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13623.308 ± 531.513 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13757.331 ± 373.905 ms/op</div><div style="clear:both;" class=""><br class=""></div><div style="clear:both;" 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</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 12772.517 ± 227.409 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13456.228 ± 498.724 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13727.211 ± 476.491 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13122.838 ± 246.673 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13082.768 ± 405.194 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13905.753 ± 456.474 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13503.479 ± 351.191 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13365.138 ± 380.285 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13842.509 ± 487.629 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13965.286 ± 330.423 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13615.975 ± 352.590 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13564.777 ± 452.947 ms/op</div><div style="clear:both;" class="">JmhPhilosophers.runOperation ss 40 13720.022 ± 519.965 ms/op</div><div style="clear:both;" class="">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 style="clear:both;" class=""><span class=""><span class=""><br class=""></span></span></div><div style="clear:both;" class=""><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 style="clear:both;" class=""><span class=""><span class=""><br class=""></span></span></div><div style="clear:both;" class=""><span class="">Maybe I need to find some more stable tests anyway.</span></div><div style="clear:both;" class=""><span class=""><br class=""></span></div><div style="clear:both;" class=""><span class=""><br class=""></span></div><div style="clear:both;" class=""><span class=""><br class=""></span></div><div style="clear:both;" class=""><span class="">Best,</span></div><div style="clear:both;" class=""><span class="">Xiaolin</span></div><div style="clear:both;" class=""><br class=""></div><blockquote style="margin-right: 0px; margin-top: 0px; margin-bottom: 0px; font-family: Tahoma, Arial, STHeiti, SimSun; font-size: 14px;" class=""><div style="clear:both;" class="">------------------------------------------------------------------</div><div style="clear:both;" class="">From:Vladimir Kempik <<a href="mailto:vladimir.kempik@gmail.com" class="">vladimir.kempik@gmail.com</a>></div><div style="clear:both;" class="">Send Time:2022年9月8日(星期四) 20:24</div><div style="clear:both;" class="">To:郑孝林(云矅) <<a href="mailto:yunyao.zxl@alibaba-inc.com" class="">yunyao.zxl@alibaba-inc.com</a>></div><div style="clear:both;" class="">Cc:riscv-port-dev <<a href="mailto:riscv-port-dev-retn@openjdk.org" class="">riscv-port-dev-retn@openjdk.org</a>>; Aleksey Shipilev <<a href="mailto:shade@redhat.com" class="">shade@redhat.com</a>>; <a href="mailto:riscv-port-dev@openjdk.org" class="">riscv-port-dev@openjdk.org</a> <<a href="mailto:riscv-port-dev@openjdk.org" class="">riscv-port-dev@openjdk.org</a>></div><div style="clear:both;" class="">Subject:Re: RVC by default?</div><div style="clear:both;" class=""><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></blockquote></div></div></div></blockquote></div><br class=""></div></body></html>