Request for review- RFE 8005716 (original) (raw)

BILL PITTORE bill.pittore at oracle.com
Thu Mar 7 10:45:02 PST 2013

On 3/7/2013 1:18 PM, Jeremy Manson wrote:

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 JNIOnLoad 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 JNIOnLoadL function exported by the library Hows this sound. * If the filename argument, when stripped of any platform-specific library * prefix, path, and file extension, indicates a library whose name is, * for example, L, and a native library called L is statically linked * with the native application or the VM (which itself may be statically * linked into the native application), then the JNI_OnLoad_L * function exported by the library is invoked rather than attempting * to load a dynamic library.

bill

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_ _<mailto:bob.vandette at oracle.com>> wrote: On Mar 5, 2013, at 7:36 PM, Dean Long wrote: > If JNIONLOADSYMBOLS contains something like "JNIOnLoad at 8" on Windows, you can't just > turn that into "JNIOnLoad at 8" + . I think it needs to be > "JNIOnLoad" + + "@8" > Good catch Dean. > Looks like onLoadSymbols[] is unused in JavajavalangClassLoader00024NativeLibraryfindBuiltinLib(). > > Instead of adding getProcessHandle(), why not add JVMFindBuiltinLibraryEntry() 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 JNIVERSION18. 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 <mailto: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/viewbug.do?bugid=8005716 >> >> The webrevs are here: >> >> http://cr.openjdk.java.net/~bpittore/8005716/jdk-webrev.00/ <http://cr.openjdk.java.net/%7Ebpittore/8005716/jdk-webrev.00/> >> http://cr.openjdk.java.net/~bpittore/8005716/hs-webrev.00/ <http://cr.openjdk.java.net/%7Ebpittore/8005716/hs-webrev.00/> >> >> The main piece of functionality is to check for the presence of JNIOnLoadlibname 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 >

More information about the hotspot-dev mailing list