Natively Compiled Code

The Java language was designed for a platform-independent, secure development model. To accomplish these goals, some execution performance was sacrificed. Translating Java bytecodes into machine instructions degrades performance. To regain some of the performance loss, you may choose to natively compile certain classes. For example, you may decide to natively compile code with CPU intensive classes.

Without native compilation, the Java code you load to the server is interpreted and the underlying core classes upon which your code relies (java.lang.*) are natively compiled.

Native compilation provides a speed increase ranging from two to ten times the speed of the bytecode interpretation. The exact speed increase is dependent on several factors, including:

• use of numerics

• degree of polymorphic message sends

• use of direct field access, as opposed to accessor methods

• amount of Array accessing

• casts

Because Java bytecodes were designed to be compact, natively compiled code can be considerably larger than the original bytecode. However, because the native code is stored in a shared library, it is shared among all users of the database.

Most JVMs use Just-In-Time compilers that convert the Java bytecodes to native machine instructions when methods are invoked. The JServer Accelerator uses an Ahead-Of-Time approach to recompiling the Java classes.

Native Compiler	Description
Just-In-Time	Provides the JVM the ability to translate the Java instructions just before needed by the JDK. The benefits depends on how accurately the native compiler anticipates code branches and the next instruction. If incorrect, no performance gain is realized.
Ahead-Of-Time	The Jserver Accelerator natively compiles all Java code within a JAR file into native shared libraries, which are organized by Java package, before execution time. At runtime, JServer Accelerator checks if a Java package has been natively compiled; and if so, uses the machine code library instead of interpreting the deployed Java code.

This static compilation approach provides a large, consistent performance gain, regardless of the number of users or the code paths they traverse on the server. After compilation, the tool loads the statically compiled libraries into JServer, which are then shared between users, processes, and sessions.

JServer Accelerator Overview

Most Ahead-Of-Time native compilers compile directly into a platform-dependent language. For portability requirements, this was not feasible. As shown in Figure 6-1, the JServer Accelerator translates the Java classes into a version of C that is platform-independent. This C code is compiled and linked to supply the final platform-dependent, natively compiled shared libraries or DLLs.

Figure 6-1 Native Compilation using JServer Accelerator

Given a JAR file, the JServer Accelerator performs the following:

1. The classes, loaded in the database, are verified.

2. The Java bytecodes for these classes are retrieved from the database and stored in a project directory where the JServer Accelerator was invoked.

3. The Java bytecodes are translated to C.

4. The C code is compiled and linked with the C compiler for your platform.

   JServer Accelerator translates, compiles, and links the retrieved classes on the client. For this reason, you must natively compile on the intended platform environment that this application will be deployed to. The result is a single deployment JAR file for all classes within the project.

5. The resulting shared library is loaded into the
   $ORACLE_HOME/javavm/admin directory.

   Note: The JServer Accelerator natively compiled libraries can only be used within JServer. Also, these libraries can only be used within the same version of JServer that it was produced in. If you want your application to be natively compiled on subsequent releases, you must recompile these classes. That is, native recompilation of existing libraries will not be performed automatically by any upgrade process.

JServer Core Java Class Libraries

All core Java class libraries and Oracle-provided Java code within JServer is natively compiled for greater execution speed. Java classes exist as shared libraries in $ORACLE_HOME/javavm/admin, where each shared library corresponds to a Java package. For example, orajox8java_lang.so on Solaris and orajox8java_lang.dll on Windows NT hold java.lang classes. Specifics of packaging and naming can vary by platform. The Aurora JVM uses natively compiled Java files internally and opens them, as necessary, at runtime.

Natively Compiling Java Application Class Libraries

The JServer Accelerator can be used by Java application products that need an performance increase and are deployed on JServer. The JServer Accelerator command-line tool, ncomp, natively compiles your code and loads it in JServer. However, in order to use ncomp, you must first provide some initial setup.

Installation Requirements

You must install the following before invoking JServer Accelerator:

1. Install a C compiler for the intended platform on the machine you are running ncomp.

2. Verify that the correct compiler and linker commands are referenced within the System*.properties file located in the $ORACLE_HOME/javavm/jahome directory. Since the compiler and linker information is platform-specific, the configuration for these items is detailed in the README for your platform.

3. Grant the user that executes ncomp the following role and security permissions:

   Note: DBA role contains both the JAVA_DEPLOY role and the FilePermission for all files under $ORACLE_HOME.

   1. JAVA_DEPLOY: The user must be assigned to the JAVA_DEPLOY role in order to be able to deploy the shared libraries on the server, which both the ncomp and deploync utilities perform. For example, the role is assigned to DAVE, as follows:

      SQL> GRANT JAVA_DEPLOY TO DAVE;
      
      

   2. FilePermission: JServer Accelerator stores the shared libraries with the natively compiled code on the server. In order for JServer Accelerator to store these libraries, the user must be granted FilePermission for read and write access to directories and files under $ORACLE_HOME on the server. One method for granting FilePermission for all desired directories is to grant the user the JAVASYSPRIV role, as follows:

      SQL> GRANT JAVASYSPRIV TO DAVE;
      
      

      See the Security chapter in the Oracle8i Java Developer's Guide for more information JAVASYSPRIV and granting FilePermission.

Executing JServer Accelerator

The following sections show how to do basic native compilation using JServer Accelerator. All ncomp options are fully described in the Oracle8i Java Tools Reference.

Note: Before you natively compile your Java server code, you must have already loaded and tested it within JServer. Native compilation of untested code is not recommended. Keep in mind that debuggers, such as the debugger provided with JDeveloper, are useful only with interpreted Java code. You cannot debug a natively compiled library.

All of the Java classes contained within a JAR file must already be loaded within the database. Execute the ncomp tool to instruct JServer Accelerator to natively compile all of these classes. The following natively compiles all classes within the pubProject.JAR file:

ncomp -user scott/tiger pubProject.JAR

Note: Because native compilation must compile and link all of your Java classes, this process may execute over the span of a few hours. The time involved in natively compiling your code depends on the number of classes to compile and the type of hardware on your machine.

If you change any of the classes within this JAR file, JServer Accelerator recompiles the shared library for the package that contains the changed classes. It will not recompile all shared libraries. However, if you want all classes within a JAR file to be recompiled--regardless of whether they were previously natively compiled--you execute ncomp with the -force option, as follows:

ncomp -user scott/tiger -force pubProject.JAR

For more options, see the Oracle8i Java Tools Reference.

---