Unsafe making too strong assumptions about array alignment?

[some-java-user-99206970363698485155 at vodafonemail.de]

Yes, that is what I meant. But I am not sure if compact object headers 
would be really a problem. I think in that case for example 
ARRAY_BYTE_BASE_OFFSET would simply be < 16, but since that base offset 
is included in the offset value passed to `putLongUnaligned`, it would 
detect alignment / misalignment correctly. The problem I was thinking of 
is rather if it can happen that the native address of the array is not 
actually aligned by 8 (the size of a long). Which would not be 
noticeable by `putLongUnaligned` since the address of the array is 
unknown to it, and it would make wrong conclusions about whether the 
access is aligned or not.

A few days ago I accidentally only responded to Maurizio instead of the 
mailing list. I will repeat my message here:

My concern here is that the code in `putLongUnaligned` decides if it is 
an unaligned store just based on the `offset`, and I am wondering if 
that information alone is really enough to tell that.
Because if it determines that the store is aligned it delegates to 
`putLong` and that requires that the store is aligned, if that is not 
actually the case it is undefined behavior (if I understand it correctly).

So this means the JVM must guarantee that the physical address of the 
array is aligned by 8 to make sure `putLongUnaligned` for a byte[] is 
actually safe?

-----------

Am 27.05.2025 um 18:53 schrieb Andrew Haley:
> On 5/26/25 13:23, Maurizio Cimadamore wrote:
>> But, as Andrew suggests, if `base` is guaranteed to be a multiple of 8,
>> we can effectively ignore it for the purpose of the modulo operator
>> (e.g. N + X % 8 == X if N % 8 == 0).
>>
>> Because of this,_under that assumption_, the Unsafe Java code is
>> correct -- e.g. it will never attempt to perform an aligned store at an
>> unaligned physical address.
>
> Well, yes. Which was OP's point, I think. `base` isn't really 
> guaranteed to be a multiple of 8 on all VMs, and as Rémi said, may 
> soon not be on HotSpot.
>