[foreign-memaccess] RFR 8226949: Move memory access API to incubator module

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Jun 28 14:51:56 UTC 2019


Hi,
this patch moves the foreign memory access API to a separate incubator 
module (jdk.incubator.foreign).

It was a bit tricky to get this right, given the many dependencies we 
have on java.base. We have the following constraints:

* VarForm is package-private in j.l.invoke, and that means that 
MemoryAddressVarHandle base should also live in there - which basically 
means that all the generated classes and AddressVarHandleGenerator 
should stay there too

* Buffer is also package-private, which means that we can't just move 
the scoped buffer implementations somewhere else

This means that all the generated classes (for var handles and buffers) 
stay where they are.

Now, there are a couple of dependencies between such generated classes 
(which will remain in java.base) and the mem access API:

* the memory access var handles need to be able to call 
MemoryAddressImpl::checkAccess, MemoryAddress::getUnsafeOffset and 
MemoryAddress::getUnsafeBase

* the scoped buffer classes need to be able to call 
MemorySegmentImpl::checkValidState

To workaround this problem, I resorted to a couple of "proxy" interfaces 
which I put under java.base/jdk.internal.access.foreign

There's also an issue with the Unsafe changes, since the methods added 
to Unsafe also depend on signatures defined in the incubator module. The 
workaround there is to create an 'unsafe' non-exported package under 
jdk.incubator.foreign. This means that if people really want to access 
unsafe capabilities of the API, they will have to do e.g. --add-exports 
jdk.incubator.foreign/jdk.incubator.foreign.unsafe=ALL-UNNAMED to obtain 
access (which means that, if you run with the default configuration, 
access to the ForeignUnsafe class is forbidden).

As with all incubator modules, since these modules are not resolved by 
default, the flag "--add-modules jdk.incubator.foreign" has to be 
specified, both at compile-time and at runtime.

Webrev:

http://cr.openjdk.java.net/~mcimadamore/panama/8226949/

Cheers
Maurizio




More information about the panama-dev mailing list