On Mon, 26 Feb 2024 15:10:55 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org>
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review comments
>
> src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 328:
>
>> 326: * physical address 1010.</li>
>> 327: * <li>The starting physical address of a {@code long[]} array will be
>> 8-byte aligned
>> 328: * (e.g. 1000), so that successive long elements occur at 8-byte
>> aligned addresses
>
> I believe there might be other changes required. I see the following
> sentences in the javadoc:
>
>
> * In other words, heap segments feature a (platform-dependent)
> <em>maximum</em>
> * alignment which is derived from the size of the elements of the Java array
> backing the
> * segment, as shown in the following table:
> ```
>
>
> * In such circumstances, clients have two options. They can use a heap
> segment backed
> * by a different array type (e.g. {@code long[]}), capable of supporting
> greater maximum
> * alignment. More specifically, the maximum alignment associated with {@code
> long[]} is
> * set to {@code ValueLayout.JAVA_LONG.byteAlignment()} which is a
> platform-dependent
> * value (set to {@code ValueLayout.ADDRESS.byteSize()}). That is, {@code
> long[]}) is
> * guaranteed to provide at least 8-byte alignment in 64-bit platforms, but
> only 4-byte
> * alignment in 32-bit platforms:
> ```
>
> ```
> * In practice, the Java runtime lays out arrays in memory so that each
> n-byte element
> * occurs at an n-byte aligned physical address (except for {@code long[]} and
> * {@code double[]}, where alignment is platform-dependent, as explained
> below).
> ```
I got the second one already. Will modify the 1st and 3rd
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18007#discussion_r1502882211
