[foreign-abi] RFR: JDK-8248809: Consider supporting address dereference/allocation for platforms where pointers are not 64 bits

[Jorn Vernee]

On Fri, 4 Sep 2020 17:46:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch makes support for addresses more uniform, in a way that scales to platforms whose pointer size might be !=
> 64 bits. After considering a number of alternatives, we settled on something which, I think is pleasing for a number of
> rteasons.  First, we added a new layout, namely `MemoryLayouts.ADDRESS`. This is the layout of a machine pointer, in
> the platform in which the JVM runs. This is a useful piece of information to have regardless.
> This new layout is then used in two places:
> 
> * In MemoryAccess, to decide whether we need a 32 or a 64 dereference handle to get/set addresses
> 
> * In NativeScope, again, to decide to which NativeScope factory we should delegate (the long vs. the int one)
> 
> This should slightly generalize what we have and also adds some extra helper methods to NativeScope which were dropped
> in an earlier iteration, waiting for this issue to be addressed.
> I've tweaked the NativeScope test in order to stress the new address-accepting factories.

Marked as reviewed by jvernee (Committer).

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/NativeScope.java line 188:

> 186:      * Allocate a block of memory in this native scope with given layout and initialize it with given address
> value. 187:      * The address value might be narrowed according to the platform address size (see {@link
> MemoryLayouts#ADDRESS}). 188:      * The segment returned by this method is associated with a segment which cannot be
> closed. Moreover, the returned

This sentence seems strange.
Suggestion:

     * The segment returned by this method cannot be closed. Moreover, the returned

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

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