On 3/7/2013 10:18 AM, 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 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.
Would that require additional changes to the JNI spec? Is there an
advantage to treating it as an unnamed library rather than
a named library (i.e. JNI_OnLoad_main)?
dl
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.vande...@oracle.com
<mailto:bob.vande...@oracle.com>> wrote:
On Mar 5, 2013, at 7:36 PM, Dean Long wrote:
> If JNI_ONLOAD_SYMBOLS contains something like "_JNI_OnLoad@8" on
Windows, you can't just
> turn that into "_JNI_OnLoad@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.pitt...@oracle.com
<mailto:bill.pitt...@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/%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
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
>
