[foreign-memaccess+abi] RFR: 8291473: Unify MemorySegment and MemoryAddress [v5]

[Radoslaw Smogura]

On Thu, 28 Jul 2022 17:13:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch implements the changes described in [1].
>> 
>> The main things to notice are the removal of `MemoryAddress` and `Addressable`. Everything else falls from that.
>> 
>> There are some changes to the `MemorySegment` API as well, as some methods such as `segmentOffset` and `asOverlappingSlice` have been removed, and instead `MemorySegment::address` now works on heap segments too (and, clients can obtain the array of an heap segment using its `array` method). So, these methods can, if needed, be implemented outside the core API.
>> 
>> `MemorySegment::equals` now compares the segments address, which is the most useful comparison when working with native interop (again, client can implement deeper comparison using `mismatch`).
>> 
>> Finally, restricted factories accepting raw addresses (in `MemorySegment` and `VaList`) have been tweaked to accept a long value instead.
>> 
>> `VaList` also needed some adjustments, since it builds on top of segments. The API is similar to before - but instead of having an address accessor, it has a zero-length segment accessor.
>> 
>> `ValueLayout.OfAddress` has a new method to create *unsafe* address layouts which return segment with maximal size (`Long.MAX_VALUE`). I've used these layouts in a lot of places in the implementation internal, which simplifies things quite a bit (e.g. removing the need to create a new segment from an address).
>> 
>> There are several test and microbenchmark updates, but relatively minor, and all caused by removal of `MemoryAddress`/`Addressable`. Changes here should be relatively simple to follow.
>> 
>> While the javadoc is ok, I didn't put too much effort in trying to provide a complete and cohesive story on how zero-length segments are used to model raw addresses. I'm working on some more extensive doc changes on the side, but I wanted to split the javadoc changes from the impl changes, so as to simplify the review work. I hope that makes sense.
>> 
>> [1] - https://mail.openjdk.org/pipermail/panama-dev/2022-July/017181.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing copyright headers
>   Revert BulkMismatchAcquire benchmark
>   Fix misc issues in tests and benchmarks

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 261:

> 259:      * {@return the Java array associated with this memory segment, if any}
> 260:      */
> 261:     Optional<Object> array();

I wonder if array word is not too strict, I think what if we would use value object as a base for struct (sometime in future).

src/java.base/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java line 66:

> 64:     @Override
> 65:     public Optional<Object> array() {
> 66:         return Optional.of(base);

I wonder if we should use here `ofNullable`

-------------

PR: https://git.openjdk.org/panama-foreign/pull/694