[foreign-jextract] RFR: 8253307: Simplify code in RuntimeHelper::lookupGlobalVariable

[Athijegannathan Sundararajan]

On Fri, 18 Sep 2020 09:59:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > > While this solves the issue for for jextract which keeps LinkerLookups, as a general API usage, this should be
> > > documented then i.e, it is up to the user to keep linker lookup objects alive In the JNI world this problem does not
> > > arise because NativeLibrary is always loaded in the context of the class loader that loaded and so native libraries are
> > > alive as long as the class loader is alive.
> > 
> > 
> > We do have some javadoc covering that already.
> > Not super sure about JNI - will creating a BB from JNI code (from a random point) keep the library alive? How?
> 
> To be more explicit about the case I have in mind for JNI:
> 
> 1. start classloader
> 2. load library
> 3. obtain BB from pointer in library
> 4. share the BB with some other class loader
> 5. drop the original classloader (and the library)
> 6. problem?

Agree.

NewDirectByteBuffer
jobject NewDirectByteBuffer(JNIEnv* env, void* address, jlong capacity);

document says:

"Allocates and returns a direct java.nio.ByteBuffer referring to the block of memory starting at the memory address
address and extending capacity bytes. Native code that calls this function and returns the resulting byte-buffer object
to Java-level code should ensure that the buffer refers to a valid region of memory that is accessible for reading and,
if appropriate, writing. An attempt to access an invalid memory location from Java code will either return an arbitrary
value, have no visible effect, or cause an unspecified exception to be thrown.”

Perhaps a warning like that for "MemoryAddress.asSegmentRestricted" as well? As a separate PR

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

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