Unsafe making too strong assumptions about array alignment?
Quân Anh Mai
anhmdq at gmail.com
Wed May 28 10:31:00 UTC 2025
That is interesting, I believe the implementation is incorrect.
Unsafe::putLong does not only require that the store is aligned, it
requires that the memory into which we are writing is an int variable
(either some field or array element). As a result, merely checking for
alignment is definitely not enough.
Cheers,
Quan Anh
On Wed, 28 May 2025 at 05:30, <
some-java-user-99206970363698485155 at vodafonemail.de> wrote:
> 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.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250528/94d1ec63/attachment-0001.htm>
More information about the panama-dev
mailing list