Native Launch

Need help?

Schedule a consultation with an Azul performance expert.

Talk about OpenJDK?

Discuss with the community on the Foojay Forum.

Looking for Zing?

The Azul Zing Virtual Machine is now Azul Zulu Prime Builds of OpenJDK and part of Azul Platform Prime.

A native launch application is any application that is written in a language other than Java and calls JNI_CreateJavaVM to create the Azul Zulu Prime Builds of OpenJDK (Azul Zulu Prime JVM) and makes calls to Java code. This is usually written in C/C++ and contains the “main” function to start execution.

Invoking Native Launch with Azul Zulu Prime JVM

If Native (C/C++) applications invoke Azul Zulu Prime JVM, consider these issues before you execute your code.

Native launch application — Identify how the native app creates the VM to find possible collisions with areas used by or allocated by the Azul Zulu Prime JVM.
Consider known limitations when running native apps on Azul Zulu Prime JVM. Identify the issues by the failure messages.
Invoking the Azul Zulu Prime JVM — check for differences between a stock build and a Azul Zulu Prime JVM build.
Native apps should also know how to run Azul Zulu Prime JVM specific features such as the Tick Profiler mechanism and C-Heap Leak detection.

Consult the cases listed below to determine your best course of action:

Bad address errors for CodeCache and OopTable: temporary az_mreserve failed.

 Failure message: Error: temporary az_mreserve(CodeCache) failed: Bad address  at (0xNNNNNN for 0xNNNNNN bytes)
Failure message: Error: temporary az_mreserve(OopTable) failed: Bad address  at (0xNNNNNN for 0xNNNNNN bytes)

Virtual address space collisions when native launch applications allocate memory where Azul Zulu Prime JVM allocates certain internal structures like the CodeCache and the OopTable.

Solution:

If any of the reported messages are encountered, native launch applications should try to LD_PRELOAD libc_hooks3.so or call JNI_CreateJavaVM early on in the main function before calling routines that may allocate memory.

libc_hooks3.so is available in $JAVA_ HOME/etc/zing/lib/.

Problems using signal handlers

Native launch application uses signal handlers for signals used by the Azul Zulu Prime JVM.

Solution:

Please use libjsig.so to chain user signal handlers correctly behind the Azul Zulu Prime JVM’s signal handlers. libjsig.so is available under $JAVA_HOME/jre/lib/amd64/server/libjsig.so.

Dependency on libc_hooks3.so or LD_PRELOAD libc_hooks3.so

Native launch applications will have to link against libc_hooks3.so or LD_PRELOAD libc_hooks3.so in the following scenarios:

When using -XX:+UseTickProfiler
When using -XX:+CHeapLeakDetection
When there is a collision in the low 2 GB of virtual address space

Solution:

Applications can either modify the code to load libjvm.so early or load libc_hooks3.so, which will reserve upfront the space needed for the VM in the low 2 GB of virtual address space.

libc_hooks3.so is available in $JAVA_HOME/etc/zing/lib/.

Threads can come under the tick profiler scanner and allocations can come under the leak detection scanner only after VM initialization.

Note	Starting with the Azul Zulu Prime JVM 18.12.0.0 release, native applications linked with libc_hooks2 will fail. To avoid the failure, rebuild your native application with libc_hooks3 which is in `<JAVA_HOME>/etc/zing/lib`.