[foreign-memaccess] [Rev 01] RFR: JDK-8242011: Add support for memory address combinator

[Maurizio Cimadamore]

> Following recent changes (see https://github.com/openjdk/panama-foreign/pull/77)which backport some of the goodies in
> foreign-abi into foreign-memaccess, this patch brings support for a VarHandle combinator which turns a regular memory
> access var handle into a var handle which gets/sets a MemoryAddress (e.g. instead of a long).
> This patch also addresses the general problem of the co-existence between combinators in MemoryHandles and the general
> var handle combinators in MethodHandles.
> This coexistence has always been tricky, because the combinators in MemoryHandles like to create a new 'flattened'
> memory access var handle, which provides best possible performances, and also performs certain alignment checks
> upfront.  However, if a memory access handle is adapted (e.g. the carrier type is changed) this simplistic approach no
> longer works, as, by reconstructing the memory access var handle from scratch we will also lose all the adaptations.
> The solution is to detect as to wheter the target handle is a "direct" memory access var handle or not (special
> provisions are made for the ubiquitous adaptation added on all memory access var handle creation as a workaround for
> JDK-8237349). If that's the case, and, if the stride or the offset matches the alignment constraint, then we go the
> fast/flattened path and we can adapt by reconstructing the handle from scratch. If any of these two conditions are not
> met (there's complex adaption that would be dropped on the floor, or the offset/stride parameter doesn't match with
> alignment constraint), then the slow path is taken - the target var handle is kept around and is adapted using the
> standard combinator API. This leads to a less performant VarHandle (because, unfortunately, calling addOffset()
> currently breaks C2 optimizations), but also guarantees that alignment constraints will be checked in full (this is
> because the memory access var handle implementation always checks the alignment of the base address passed to it - only
> for the offset part is the alignment check skipped - on the basis that this has already been verified by
> construction).  The result is that we can lift a lot of the restrictions surrounding the combinators in MemoryHandles;
> such combinators can now work on _any_ var handle (provided the var handle has a first coordinate type of type
> MemoryAddress). Also, I've lifted the alignment restrictions, since these will either be enforced dynamically (by
> taking the slow path), or they won't be enforced because we have already statically proven that the constraints are
> satisfied (fast path).  I've also took the chance to rename some of the classes surrounding memory access var handles
> to use the "memory access var handle" terminology, which is the one that stuck (currently, some classes use the word
> "address var hande" which is ambiguous).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  * Added support for dropCoordinates VH adapter
  * relaxed restriction on stride/offset - now both can be either negative, or zero; if zero, the adapter will try to do as
    little work as possible
  * added more tests

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

Changes:
  - all: https://git.openjdk.java.net/panama-foreign/pull/84/files
  - new: https://git.openjdk.java.net/panama-foreign/pull/84/files/d3dc0fc3..3fc29ff3

Webrevs:
 - full: https://webrevs.openjdk.java.net/panama-foreign/84/webrev.01
 - incr: https://webrevs.openjdk.java.net/panama-foreign/84/webrev.00-01

  Stats: 165 lines in 5 files changed: 144 ins; 5 del; 16 mod
  Patch: https://git.openjdk.java.net/panama-foreign/pull/84.diff
  Fetch: git fetch https://git.openjdk.java.net/panama-foreign pull/84/head:pull/84

PR: https://git.openjdk.java.net/panama-foreign/pull/84