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

Maurizio Cimadamore mcimadamore at openjdk.org
Thu Jul 28 17:13:18 UTC 2022


> 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

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

Changes:
  - all: https://git.openjdk.org/panama-foreign/pull/694/files
  - new: https://git.openjdk.org/panama-foreign/pull/694/files/2312cb30..18e7f605

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=panama-foreign&pr=694&range=04
 - incr: https://webrevs.openjdk.org/?repo=panama-foreign&pr=694&range=03-04

  Stats: 310 lines in 9 files changed: 307 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/panama-foreign/pull/694.diff
  Fetch: git fetch https://git.openjdk.org/panama-foreign pull/694/head:pull/694

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


More information about the panama-dev mailing list