Get the Best Performance out of Java in the Database

When you run Java in the database, what are the various execution modes? Are you taking the most efficient approach? In this post I'll touch on the various execution modes for running Java in the Oracle database.

As we all know, the best execution performance for Java is achieved via binary executables obtained through compilation (JIT compilers and/or static compilers). The Oracle Database currently furnishes a static native Java compiler known as NCOMP, which must be explictly invoked ahead of the deployment.

There are currently three execution modes: (i) fully interpret, (ii) NCOMPed System classes, and (iii) fully NCOMPed (or NCOMPed User Classes).

Fully Interpreted (System and User Classes)
In this mode, both system classes and the user classes, run interpreted. During the database installation, the non-compiled Java VM system classes are installed. By default, user classes also run interpreted and most customers stick to the default mode and are happy with the level of performance obtained, mostly because, as explained in previous posts and in my book, the combination of Java and SQL run faster in the database (even fully interpreted). However, this is not the most efficient execution mode.

NCOMPed System Classes and Interpreted User Classes
In this mode, the system classes run natively compiled while user classes run interpreted. The natively compiled system classes (NCOMP libraries) are installed explictly following the default database install, from the companion CD. Without further explcit action, the user classes run interpreted on top of the natively compiled system classes. The overall peformance is greater than the previous mode (i.e., fully interpreted).

Fully NCOMPed (System and User Classes)
In this mode, the system and user classes run natively compiled. User NCOMP requires an explicit action from the developers. It comprises three commands/steps: 'NCOMP', 'STATUSNC', and 'DEPLOYNC'.

NCOMP

This command takes Java bytecodes that have been resolved and verified during the loading phase (loadjava) and can therefore be trusted and expected to execute correctly, then does three things:

1. gathers class info, generates a script that will drive the NCOMPing process, and produces the list of NEED_NCOMPNG orALREADY_NCOMPED methods
2. Pauses for the Java-to-C translation: C compilation and linkage of each package involved into platform-specific DLLs
3. Deployment/installation of the resulting DLL (unless -noDeploy) is specified

ncomp [ options ] class_designation_file
-user -u username/password [@database_url]
[-load]
[-projectDir -d project_directory]
[-force]
[-lightweightDeployment]
[-noDeploy]
[-outputJarFile -o jar_filename]
[-thin]
[-oci -oci8]
[-update]
[-verbose]

STATUSNC

This command checks whether the JAR files, ZIP files, or CLASSES files are NCOMPed or not.
statusnc [ options ] .jar .zip
.classes.
-user /[@database]
[-output -o ]
[-projectDir -d ]
[-thin]
[-oci -oci8]

DEPLOYNC

This command deployd the natively compiled deployment JAR file, to the database.
deploync [options] deployment.jar
-user -u username/password [@database_url]
[-projectDir -d project_directory]
[-thin]
[-oci -oci8]

Conclusions

NCOMP may give an order of magnitude speed up (i.e., 10 times) compared to interpreted execution. But as usual, there is no absolute figure; it all depends on what exactly you are NCOMPing as NCOMP speeds up only Java code, not the embedded SQL.

See more details in the Java Developer's Guide of the Oracle Database documentation nd in my book.