Skip to content

Compiling Java Stored Procedures Using Native Compilation Takes Longer Time in 12.2 Compared to Lower Releases


Oracle Database – Enterprise Edition – Version and later
Information in this document applies to any platform.


Compiling Java stored procedure(s) using “-nativecompile” option with either the loadjava utility or with the DBMS_JAVA package takes longer time in 12.2.0.x version when compared to lower versions.

In 12.2.0.x.0:

SQL> exec dbms_java.loadjava(‘-v -r -nativecompile /temp/Test.jar’);

PL/SQL procedure successfully completed.

Elapsed: 00:02:03.85

In 12.1.0.x or lower, loading the same Test.jar file takes much lesser time.

SQL> exec dbms_java.loadjava(‘-v -r -nativecompile /temp/Test.jar’);

PL/SQL procedure successfully completed.

Elapsed: 00:00:08.97

Similar performance is observed with loadjava utility as well when using -nativecompile option.

NOTE: Test.jar contains 4 class files and shown here only for demonstration purpose. Its not uploaded anywhere in this document since the performance issue can be reproduced with any jar/zip files.

The time taken to compile the jar/zip file depends on the number of java source/class files it contains. Total time increases with increase in the number of files in the jar/zip.


Upgraded the database to 12.2.0.x.0.


This issue was logged as bug 25942370 which got closed as not a bug since the behavior of -nativecompile option in 12.2 is the expected one.

From 12.2 and above, then JIT (Just-In-Time) compiler does a static profiling of the non-profiled code, that is the code that has not yet been executed.This is a new feature in 12.2 and the static profiling is always done when using -nativecompile option. The JIT aggressively assumes that all the codes are candidates for optimization and the difference in the compilation speed is largely due to the optimizations being done based on this static code analysis.


To obtain the performance of lower versions, any of the following features of the JIT can be disabled.

1) Disable the static profiling feature of the JIT compiler as below.

CALL DBMS_JAVA.SET_NATIVE_COMPILER_OPTION(‘optimizerStaticProfileAnalysis’, False’);

2) Alternatively, aggressive method inlining can be disabled as below

CALL DBMS_JAVA.SET_NATIVE_COMPILER_OPTION(‘optimizerInlineExternalMethods’, ‘False’);

3) And a final alternative is to disable method inlining entirely as below.

CALL DBMS_JAVA.SET_NATIVE_COMPILER_OPTION(‘optimizerMethodInlining’, ‘False’);

Above options are just a workaround. Instead of using any of the above workaround, Oracle suggest not to use the -nativecompile option which compiles all the method natively and let the JIT compiler decide which method to be compiled natively based on the profiling data collected at the execution time. After a period of time, then performance of java code not compiled with -nativecompile option will be as good as the one compiled with -nativecompile option.

%d bloggers like this: