Feature requests.

[Maurizio Cimadamore]

I second what Paul said. Alignment of heap memory is not something FFM 
API supports, as much it is something FFM knows how to "cope" with.

That is, the only thing we know and can rely upon, is that an heap array 
of type T can provide no more alignment than T itself (this is what we 
mean when we say, in the Javadoc, that address of heap segments is 
"virtualized").

This means that an int[] can provide up to 4-byte alignment, a long[] 
can provide up to 8-byte alignment and so on.

If you need 16-byte alignment there's currently no bullet proof way to 
get there. Which is why all access operations with alignment > 8 bytes 
will fail on a heap memory segment, regardless of the source.

This alignment-agnostic design has allowed FFM to coexist with radical 
enhancements that squeezed object layouts down to 8 bytes (such as 
Project Lillput [1]) -- we have seen how the BB API required some 
adjustments in this area to cope with that [2].

So, as Paul says, I don't expect any significant change in this area -- 
as overcommitting to alignment of heap memory will likely result in less 
freedom for the JVM runtime and GC design.

To help navigate this area, there's a new method [3] since Java 23 which 
allows developers to know the max alignment supported by a given memory 
segment (whether heap or native).

Cheers
Maurizio

[1] - https://openjdk.org/jeps/450
[2] - https://github.com/openjdk/jdk/pull/16681
[3] - 
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/lang/foreign/MemorySegment.html#maxByteAlignment()

On 19/05/2025 16:51, Paul Sandoz wrote:
> Note that will not guarantee stable alignment. The GC can move the 
> allocated array.
>
> I don’t know if we will ever get to supporting hyper-aligned heap 
> objects, it's likely complex for GCs to support and to surface that up 
> to developers. There are more important things to work on.
> Paul.
>
>> On May 19, 2025, at 6:18 AM, Per-Ake Minborg 
>> <per-ake.minborg at oracle.com> wrote:
>>
>> Hi again Lee!
>>
>> 1.
>>
>> The VM/GC has its own rules for how arrays are allocated, and so, 
>> there is no way (at least not now) to control primitive array 
>> alignment except for the way you mentioned — a primitive array is 
>> always aligned to its component's natural alignment. A very simple 
>> way to allocate and align heap arrays could be to implement a method 
>> similar to this one:
>>
>>
>> static MemorySegment heapSegment(MemoryLayout layout) {
>>    byte[] arr = new byte[(int) layout.byteSize() * 
>> (int)layout.byteAlignment() - 1];
>>    SegmentAllocator allocator = 
>> SegmentAllocator.slicingAllocator(MemorySegment.ofArray(arr));
>>    return allocator.allocate(layout);
>> }
>>
>> If memory efficiency is a concern, a more complex solution can be 
>> written that leverages the implicit alignment of arrays 
>> of|int| and|long.|
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20250520/725a52cc/attachment-0001.htm>