RVC by default?

Mon Sep 19 21:27:02 UTC 2022

Hello
Some numbers on performance, 100% - time of average philosophers run on repetitions 4-9 ( filtering out some too slow results), on default jdk19 without RVC
to make results more a less repeatable, I had to "isolate" 2 of 4 harts, from the rest of the system. These two harts can only  be assigned to the process explicitly.
Basically, two harts are running only java threads. Java threads are running only on these two harts. This minimizes an effect of other processes on the result ( especially on low-clocked fpga cores).

jdk19  - 100% +- 4%
jdk19 + JDK-8294012 - 100% +- 4%
jdk19 + unaligned access patch from Xiaolin  + JDK-8294012  -  102 % +- 2.5 %
jdk19 + unaligned access patch from Xiaolin  + JDK-8294012 + UseRVC - 95% +- 1%

Regards, Vladimir

> 16 сент. 2022 г., в 14:49, Vladimir Kempik <vladimir.kempik at gmail.com> написал(а):
> 
> Hello.
> I have applied your two fixes on top of jdk19 and tested - all issues have gone, thanks.
> Looks like the source of the issues is in my m-mode.
> 
> Kinds Regards, Vladimir
> 
>> 16 сент. 2022 г., в 11:45, Xiaolin Zheng <yunyao.zxl at alibaba-inc.com <mailto:yunyao.zxl at alibaba-inc.com>> написал(а):
>> 
>> Hi Vladimir,
>> 
>> Thank you for the newly-added hs_err and further tests. I guess it might have some relationship with the discussed [misaligned issue](https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000559.html <https://mail.openjdk.org/pipermail/riscv-port-dev/2022-July/000559.html>) here. But just guessing. I have noticed one interesting thing that the crashed hs_err files are often like:
>> 
>> ```
>> ...
>>   0x0000003f7cc2f91e:   mv a0,s7
>>   0x0000003f7cc2f922:   auipc t0,0x10494
>>   0x0000003f7cc2f926:   jalr 664(t0) # 0x0000003f8d0c3bba = AdapterHandlerEntry::print_adapter_on(outputStream*) const+470   <--- ??? Misaligned address: 0x0000003f7cc2f926
>>   0x0000003f7cc2f92a:   sd zero,704(s7)
>>   0x0000003f7cc2f92e:   sd zero,712(s7)
>> ...
>> ```
>> 
>> With RVC, it is certainly legal to locate at a 2-byte aligned address. But, this location is relocatable, which means it will be patched.
>> 
>> So, I might doubt something weird happened when performing the patching behavior. The patching logic, referencing the instruction segment, does not care about the alignment but only performs 4-byte memory load operations, such as Assembler::patch(). On machines having the misaligned address support, it would not go wrong of course; but it seems that our FPGA board discussed lacks this support. So I guess there might be an interesting chemical reaction happening here. I have written two patches to debug this issue and released one fastdebug build only for debugging purposes, and I put it at https://github.com/zhengxiaolinX/jdk/releases/tag/test-unaligned <https://github.com/zhengxiaolinX/jdk/releases/tag/test-unaligned>. The two patches fix most of the misaligned accesses to the instruction segment. I was wondering if you could have a simple test of it when you are available, to see whether this issue still exists?
>> 
>> I am just guessing the problem here, hope it can reveal something to us.
>> 
>> Thank you very much.
>> 
>> Best,
>> Xiaolin
>> 
>> ------------------------------------------------------------------
>> From:Vladimir Kempik <vladimir.kempik at gmail.com <mailto:vladimir.kempik at gmail.com>>
>> Send Time:2022年9月15日(星期四) 23:25
>> To:郑孝林(云矅) <yunyao.zxl at alibaba-inc.com <mailto:yunyao.zxl at alibaba-inc.com>>
>> Cc:riscv-port-dev <riscv-port-dev-retn at openjdk.org <mailto:riscv-port-dev-retn at openjdk.org>>; Aleksey Shipilev <shade at redhat.com <mailto:shade at redhat.com>>; riscv-port-dev at openjdk.org <mailto:riscv-port-dev at openjdk.org> <riscv-port-dev at openjdk.org <mailto:riscv-port-dev at openjdk.org>>
>> Subject:Re: RVC by default?
>> 
>> Hello
>> Looks pretty similar to me.
>> for me it was vanilla recent jdk19 
>> But later, when I backported next patches to my jdk19 branch, the issue became different ( Arena alloc issue I have reported earlier):
>> 
>> 8290496: riscv: Fix build warnings-as-errors with GCC 11
>> 8290280: riscv: Clean up stack and register handling in interpreter
>> 8290137: riscv: small refactoring for add_memory_int32/64
>> 8290164: compiler/runtime/TestConstantsInError.java fails on riscv
>> 8291952: riscv: Remove PRAGMA_NONNULL_IGNORED
>> 8291947: riscv: fail to build after JDK-8290840
>> 8291893: riscv: remove fence.i used in user space Backport-of:...
>> 8292713: Unsafe.allocateInstance should be intrinsified without UseUnalignedAccesses
>> 8292867: RISC-V: Simplify weak CAS return value handling
>> 8292407: Improve Weak CAS VarHandle/Unsafe tests resilience under spurious failures
>> 8293100: RISC-V: Need to save and restore callee-saved FloatRegisters in...
>> 8293050: RISC-V: Remove redundant non-null assertions about macro-assembler
>> 8293474: RISC-V: Unify the way of moving function pointer
>> 8293524: RISC-V: Use macro-assembler functions as appropriate
>> 8293566: RISC-V: Clean up push and pop registers
>> 
>> I’m gonna bisect this list and find what changed the behaviour.
>> 
>> The workaround says - update to ubuntu 21.04, but its not clear - update runtime environment or build environment.
>> For me the runtime is ubuntu 22.04, but I build the jdk with sysroot of ubuntu 20.04 ( for better compatibility) and gcc 11.2
>> 
>> Regards, Vladimir
>> 15 сент. 2022 г., в 18:17, Xiaolin Zheng <yunyao.zxl at alibaba-inc.com <mailto:yunyao.zxl at alibaba-inc.com>> написал(а):
>> 
>> Hi Vladimir,
>> 
>> The mailing list says my e-mail exceeds 40KB so I get rejected. But I want to send it out anyway before getting off today's work. So here is a work around:
>> Please check:
>> https://gist.github.com/zhengxiaolinX/25c32853690f7ac1c125d2fe1da19710 <https://gist.github.com/zhengxiaolinX/25c32853690f7ac1c125d2fe1da19710>
>> 
>> Looking forward to your opinions.
>> 
>> Best,
>> Xiaolin
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/riscv-port-dev/attachments/20220920/14178306/attachment-0001.htm>