On 4 Jun 2013, at 15:16, Bob Vandette <[email protected]> wrote:
> > On Jun 4, 2013, at 3:53 AM, Steve Poole wrote: > >> Thanks Bob - appreciate your time to give me more information. I have one >> more question! >> >> I could interpret this statement in your spec change >> >> "A library L whose image has been combined with the VM is defined as >> statically linked if and only if the library exports a function called >> JNI_OnLoad_L." >> >> as indicating that I can take an existing dynamic library L and by adding an >> JNI_OnLoad_L entry point I can expect that it will be called at 'dynamic' >> load time. >> >> Since the wider definition of 'statically linked' is implementation >> dependent it would be reasonable for an implementor to decide they wanted >> this sort of behaviour. >> However I'm not sure if that is also your intention / expectation for the >> OpenJDK reference implementation? >> > > I'm not exactly sure what you are asking? > > The fact that we left the details of how to link a library statically up to > the implementation, > should not alter the fact that a static library is NOT a dynamically linked > library. > > In the OpenJDK implementation, we limit the scope of where we look for the > JNI_OnLoad_L symbol > to the currently running executable image and will not attempt to find this > symbol in any "not yet" loaded > shared libraries. The dynamic library load process will first load the > image into memory and then > search for a JNI_OnLoad entrypoint. The static library implementation will > look for a JNI_OnLoad_L > before attempting any loading (dlopen on Linux). If found, it declares this > library to be static and > treats it as such. Otherwise it processes the library as a dynamic library. Ah! - ok got it. Thanks > > Bob. > >> >> >> On 30 May 2013, at 15:30, Bob Vandette <[email protected]> wrote: >> >>> My primary goal for implementing JEP 178 was to eliminate any specification >>> barriers in JDK 8 that would prohibit the >>> implementation of a Java application that might want to link the entire >>> Java runtime into a single application binary. >>> >>> This allows us to implement the changes that you're suggesting in a JDK 8 >>> implementation without having to >>> alter the specification. This type of spec change is typically only done >>> in major Java releases. >>> >>> We don't yet have any plans to provide the build system changes that would >>> allow an openjdk build to produce >>> a complete static library implementation. It's getting pretty late to push >>> these types of changes into JDK8 as we're pretty >>> close to feature freeze. >>> >>> As for use cases for this change, we're trying to enable the creation of >>> single Java application binaries that can take >>> advantage of newer compiler technologies such as link time optimization. >>> This feature coupled with the JDK 8 profiles will allow >>> smaller applications that bundle Java binaries to be deployed on app stores. >>> >>> >>> Bob. >>> >>> >>> On May 30, 2013, at 6:15 AM, Steve Poole wrote: >>> >>>> Thanks for the quick response Bob. >>>> >>>> This all seems quite manual - are there any plans to add support to >>>> OpenJDK to help with this process? >>>> >>>> >>>> >>>> On 29 May 2013, at 00:06, Bob Vandette <[email protected]> wrote: >>>> >>>>> >>>>> On May 28, 2013, at 7:06 AM, Steve Poole wrote: >>>>> >>>>>> >>>>>> hi everyone, >>>>>> >>>>>> I've been reading JEP 178 (Statically-Linked JNI Libraries ) >>>>>> http://openjdk.java.net/jeps/178 >>>>>> >>>>>> There is a sentence in the section on JNI Specification changes that >>>>>> says >>>>>> >>>>>> "A native library may be statically linked with the VM. The manner in >>>>>> which the library and VM image are combined is implementation-dependent." >>>>>> >>>>>> I can't find anything that explains the process in more detail so >>>>>> posting here. >>>>>> >>>>>> Basically - if I want to statically link my JNI library to Hotspot what >>>>>> are the instructions for the OpenJDK implementation? >>>>> >>>>> Since the procedure for statically linking binaries into a executable is >>>>> very platform specific, the specification >>>>> intentionally leaves out these details. >>>>> >>>>> The key functional changes that were implemented to support this spec >>>>> change, were: >>>>> >>>>> 1. Require JNI_OnLoad_{libraryname} for static libraries. >>>>> 2. Modify the Java API's that load native JNI libraries to support static >>>>> libraries by detecting the >>>>> presence of the library specific OnLoad function. >>>>> 3. Support JNI_OnUnLoad_{libraryname} >>>>> >>>>> So you can either build the entire JDK as static libraries, change every >>>>> JNI_OnLoad function to be >>>>> unique and link them all together with a java launcher. >>>>> >>>>> OR >>>>> >>>>> You can create a single static library, making sure to give it a unique >>>>> JNI_OnLoad_{libraryname} >>>>> entrypoint, link it with a program executable that loads the VM via the >>>>> Java launcher or Invocation APIs. >>>>> >>>>> For example: If your library name is speciallibrary.a, you would then >>>>> call System.loadLibrary("speciallibrary") >>>>> >>>>> Once the loadLibrary call succeeds, you can then call any native Java >>>>> methods defined by the static library. >>>>> >>>>> Bob. >>>>> >>>>> >>>>>> >>>>>> >>>>>> Cheers >>>>>> >>>>>> Steve >>>>> >>>> >>> >> >
