Missaligned memory accesses from JDK

[Justin King]

https://github.com/openjdk/jdk/pull/12078

Proposes introducing a standard interface for dealing with unaligned
loads/stores without undefined behavior.

On Mon, Mar 20, 2023, 12:03 PM Vladimir Kempik <vladimir.kempik at gmail.com>
wrote:

> Adding hs compiler list.
>
> Could you please suggest on best way to make emit_intX methods not perform misaligned memory stores ?
> Talking about src/hotspot/share/asm/codeBuffer.hpp from https://github.com/VladimirKempik/jdk/commit/18d7f399ce1bc213b2495411193938d914d3f616#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae
>
> Regards, Vladimir
>
>
>  For each emit_intX functions modified, I see there is a correspondent
> version which handles unaligned access. For example, 'void
> emit_int16(uint8_t x1, uint8_t x2)' for 'void emit_int16(uint16_t x)'
>  So if we encounter an unaligned access issue when using
> 'emit_int16(uint16_t x)', shouldn't we change the callsite to use
> 'emit_int16(uint8_t x1, uint8_t x2)' instead?
>
>
> Hello
> not exactly
> 'void emit_int16(uint8_t x1, uint8_t x2)
> will always use slow version ( store byte)
>
> but
> void emit_int16(uint16_t x)
> will use slow version only on unaligned stores. if store is aligned, it
> will use "store half", which should be faster.
>
> So we can’t always use emit_int16(uint8_t x1, uint8_t x2) at callsite.
>
> and we can’t decide which one to use at callsite as callsite should be
> unaware of end() value inside CodeSection class
>
> Regards, Vladimir
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20230320/194b5b98/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3999 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20230320/194b5b98/smime-0001.p7s>