Unaligned memory access with JDK

wangyadong (E) yadonn.wang at huawei.com
Fri Jul 29 07:41:54 UTC 2022


> Hello, Should I file a jbs bug then ?
Of course.

-----Original Message-----
From: Владимир Кемпик [mailto:vladimir.kempik at gmail.com] 
Sent: Friday, July 29, 2022 3:24 PM
To: wangyadong (E) <yadonn.wang at huawei.com>
Cc: Palmer Dabbelt <palmer at dabbelt.com>; riscv-port-dev at openjdk.org
Subject: Re: Unaligned memory access with JDK

Hello, Should I file a jbs bug then ?

I have also found misaligned access in stack setup prologue of template interp generated methods.
for example, the putstatic code:

0x3f89d033c0:  ff8a0a13          addi          s4,s4,-8
0x3f89d033c4:  00aa3023          sd            a0,0(s4)
0x3f89d033c8:  0380006f          j             56                              # 0x3f89d03400
0x3f89d033cc:  ff8a0a13          addi          s4,s4,-8
0x3f89d033d0:  00aa2027          fsw           fa0,0(s4)
0x3f89d033d4:  02c0006f          j             44                              # 0x3f89d03400
0x3f89d033d8:  ff0a0a13          addi          s4,s4,-16
0x3f89d033dc:  00aa3027          fsd           fa0,0(s4)
0x3f89d033e0:  0200006f          j             32                              # 0x3f89d03400
0x3f89d033e4:  ff0a0a13          addi          s4,s4,-16
0x3f89d033e8:  000a3423          sd            zero,8(s4)
0x3f89d033ec:  00aa3023          sd            a0,0(s4)
0x3f89d033f0:  0100006f          j             16                              # 0x3f89d03400
0x3f89d033f4:  ff8a0a13          addi          s4,s4,-8
0x3f89d033f8:  0005053b          addw          a0,a0,zero
0x3f89d033fc:  00aa3023          sd            a0,0(s4)
0x3f89d03400:  001b5683          lhu           a3,1(s6). <— MISALLIGNED ACCESS
0x3f89d03404:  00569613          slli          a2,a3,5
0x3f89d03408:  00cd0633          add           a2,s10,a2
0x3f89d0340c:  02860493          addi          s1,a2,40
0x3f89d03410:  00048493          mv            s1,s1
0x3f89d03414:  0ff0000f          fence         iorw,iorw
0x3f89d03418:  0004e483          lwu           s1,0(s1)
0x3f89d0341c:  0af0000f          fence         ir,iorw

Regards, Vladimir
> 29 июля 2022 г., в 10:03, wangyadong (E) <yadonn.wang at huawei.com> написал(а):
> 
>> IIUC most of the RISC-V OpenJDK port was done on systems that have 
>> hardware support for misaligned accesses, but even on systems that trap to M-mode the port should function correctly -- sure it'll be slow, but the support should otherwise be transparent to userspace (and even to Linux).
> 
> Agree. The RISC-V port should cover the hardware not support for user-invisible misaligned accesses.
> 
>> So my question is - risc-v cores without unaligned memory access support - are they supported by risc-v openjdk port ?
> We'll fix it, and that' great if you're interested :)
> 
> Yadong
> 
> -----Original Message-----
> From: riscv-port-dev [mailto:riscv-port-dev-retn at openjdk.org] On 
> Behalf Of Palmer Dabbelt
> Sent: Friday, July 29, 2022 5:30 AM
> To: vladimir.kempik at gmail.com
> Cc: riscv-port-dev at openjdk.org
> Subject: Re: Unaligned memory access with JDK
> 
> On Thu, 28 Jul 2022 14:22:33 PDT (-0700), vladimir.kempik at gmail.com wrote:
>> Right, the system I was playing with doesn’t have misaligned access emulation enabled in M-mode, but that can be enabled.
> 
> I suppose it's also undefined whether these accesses need to be handled in M-mode or if Linux should also do so, but there's currently no code in Linux to do that and no way for userspace to control that handling.
> 
> In the long run we probably want to stop predenting misaligned accesses are supported when they're actually emulated, via something like PR_SET_UNALIGN (and some M-mode interface).  That'd require some code, though, and either way we'd need to leave the default as is.
> 
>> THanks for clarifying, I was wondering is it a bug or a feature.
> 
> I guess it's both ;)
> 
>> 
>>> 29 июля 2022 г., в 00:19, Palmer Dabbelt <palmer at dabbelt.com> написал(а):
>>> 
>>> On Thu, 28 Jul 2022 13:50:00 PDT (-0700), vladimir.kempik at gmail.com wrote:
>>>> Hello
>>>> I was recently playing with a simple risc-v core running on an fpga and found the idk crashes on it.
>>>> It crashes with SIG_ILL : ILL_TRP, on a simple load from memory instruction.
>>>> So I figured the main issue is unaligned memory access MacroAssembler::stop() and that risc-v core was pretty simple and didn’t support unaligned memory access.
>>>> Here is what I found:
>>>> 
>>>> void MacroAssembler::stop(const char* msg) {  const char * msg1 =
>>>> ((uint64_t)msg) & ~0x07 + 0x08;  BLOCK_COMMENT(msg1); 
>>>> illegal_instruction(Assembler::csr::time);
>>>> emit_int64((uintptr_t)msg1);
>>>> }
>>>> 
>>>> and emit_64 is :
>>>> void emit_int64( int64_t x)  { *((int64_t*) end()) = x;
>>>> set_end(end() + sizeof(int64_t)); }
>>>> 
>>>> the problem is that the end() pointer is shared between emit_int64, emit_int32, emit_int8, etc, and non of them do care about natural memory alignment for processed types:
>>>> 
>>>> void emit_int32(int32_t x) {
>>>>   address curr = end();
>>>>   *((int32_t*) curr) = x;
>>>>   set_end(curr + sizeof(int32_t));
>>>> }
>>>> 
>>>> void emit_int8(int8_t x1) {
>>>>   address curr = end();
>>>>   *((int8_t*)  curr++) = x1;
>>>>   set_end(curr);
>>>> }
>>>> 
>>>> So my question is - risc-v cores without unaligned memory access support - are they supported by risc-v openjdk port ?
>>> 
>>> Support for misaligned accesses lives in a weird grey area in RISC-V: misaligned accesses used to be mandated by the ISA, but that requirement was removed in 2018 via 61cadb9 ("Provide new description of misaligned load/store behavior compatible with privileged architecture.").  I just sent a patch to document this, looks like we never bothered to write it down (probably because nobody was watching for the ISA change).
>>> 
>>> That said, some implementations support misaligned accesses via a M-mode trap handler, as implementations can do essentially anything they want in RISC-V.  IIUC most of the RISC-V OpenJDK port was done on systems that have hardware support for misaligned accesses, but even on systems that trap to M-mode the port should function correctly -- sure it'll be slow, but the support should otherwise be transparent to userspace (and even to Linux).  It might be worth fixing that performance issue, but if you're seeing a SIGILL from a misaligned access then there's likely also a functional bug in the emulation routines or Linux.



More information about the riscv-port-dev mailing list