RFR: 8326172: Dubious claim on long[]/double[] alignment in MemorySegment javadoc [v2]

[Jorn Vernee]

On Mon, 26 Feb 2024 15:10:55 GMT, Maurizio Cimadamore <mcimadamore at 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