Request for review- RFE 8005716

[Jeremy Manson]

Hi guys,

I'm really glad to see you are doing this.  We've done something similar to
good effect within Google (and we'll probably drop our similar, internal
patch and pick up this patch once it is pushed).

Have you thought about support for having a JNI_OnLoad inside of a main
executable that *doesn't* have a postfixed _lib?  Our Google-internal patch
treats the main executable as a regular JNI library if you execute a
special System.loadFromLauncher() function.  We also do the same thing with
JVMTI.

Nit: The comments that read like this:

     * for example, L, and a native library called L is statically
linked     * with the VM, then the JNI_OnLoad_L function exported by
the library

Should these read "linked with the VM", or "linked with the native
application loading the VM"?

Jeremy


On Wed, Mar 6, 2013 at 8:21 AM, Bob Vandette <bob.vandette at oracle.com>wrote:

>
> On Mar 5, 2013, at 7:36 PM, Dean Long wrote:
>
> > If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad at 8" on
> Windows, you can't just
> > turn that into "_JNI_OnLoad at 8_" + <libname>.  I think it needs to be
> > "_JNI_OnLoad_"  + <libname> + "@8"
> >
> Good catch Dean.
>
>
> > Looks like onLoadSymbols[] is unused in
> Java_java_lang_ClassLoader_00024NativeLibrary_findBuiltinLib().
> >
> > Instead of adding getProcessHandle(), why not add
> JVM_FindBuiltinLibraryEntry() instead?
> > This would make it easier to support table-lookup when runtime symbol
> information is missing or not
> > supported by the platform.
>
> Bill has already factored out the implementation of getProcessHandle.
>  Although your
> approach is cleaner, I'm concerned about creating a VM version dependency.
>   For a traditional
> JRE that doesn't even require static library support, we'd have to make
> sure to run on a VM that
> support JNI_VERSION_1_8.  It looks like the JDK maintains their own copy
> of jni.h.  If they didn't
> do that, we would have already gone down that path.   The jdk sources
> already contain several
> instances of dlopen, dlysym and the Windows equivalents so I don't see a
> need to add a new
> VM function.
>
> Bob.
>
> >
> > dl
> >
> > On 3/5/2013 3:05 PM, bill.pittore at oracle.com wrote:
> >> This request is tied to bugid 8005716 that deals with adding support
> for statically linked JNI libraries.
> >>
> >> The JEP is here: http://openjdk.java.net/jeps/178
> >>
> >> The bug is here:http://bugs.sun.com/view_bug.do?bug_id=8005716
> >>
> >> The webrevs are here:
> >>
> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/
> >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/
> >>
> >> The main piece of functionality is to check for the presence of
> JNI_OnLoad_libname to determine if the library specified by 'libname' has
> been statically linked into the VM. If the symbol is found, it is assumed
> that the library is linked in and will not be dynamically loaded.
> >>
> >> thanks,
> >> bill
> >
>
>