9 Oracle Database Java Application Performance

Overview of Oracle JVM JIT

Starting with Oracle 11g release 1 (11.1), there is a just-in-time(JIT) compiler for Oracle JVM environment. A JIT compiler for Oracle JVM enables much faster execution because, it manages the invalidation, recompilation, and storage of code without an external mechanism. Based on dynamically gathered profiling data, this compiler transparently selects Java methods to compile the native machine code and dynamically makes them available to running Java sessions. Additionally, the compiler can take advantage of Oracle JVM's class resolution model to optionally persist compiled Java methods across database calls, sessions, or instances. Such persistence avoids the overhead of unnecessary recompilations across sessions or instances, when it is known that semantically the Java code has not changed.

The JIT compiler is controlled by a new boolean-valued initialization parameter called java_jit_enabled. When running heavily used Java methods with java_jit_enabled parameter value as true, the Java methods are automatically compiled to native code by the JIT compiler and made available for use by all sessions in the instance. The VM automatically recompiles native code for Java methods when necessary, such as following reresolution of the containing Java class.

The JIT compiler runs as an MMON slave, in a single background process for the instance. So, while the JIT compiler is running and actively compiling methods, you may see this background process consuming CPU and memory resources on par with an active user Java session.

Advantages of JIT Compilation

The following are the advantages of using JIT compilation over the compilation techniques used in earlier versions of Oracle database:

• JIT compilation works transparently

• JIT compilation speeds up the performance of Java classes

• JIT stored compiled code avoids recompilation of Java programs across sessions or instances when it is known that semantically the Java code has not changed.

• JIT compilation does not require a C compiler

Methods Introduced in Oracle Database 11g

In 11g release 1 (11.1), the DBMS_JAVA package has been enhanced with the following new public methods to provide Java entrypoints for controlling synchronous method compilation and reverting to interpreted method execution:

set_native_compiler_option

This procedure sets a native-compiler option to the specified value for the current schema. If the option given by optionName is not allowed to have duplicate values, then the value is ignored.

PROCEDURE set_native_compiler_option(optionName VARCHAR2,
value VARCHAR2);

unset_native_compiler_option

This procedure unsets a native-compiler option/value pair for the current schema. If the option given by optionName is not allowed to have duplicate values, then the value is ignored.

PROCEDURE unset_native_compiler_option(optionName VARCHAR2,
value VARCHAR2);

compile_class

This function compiles all methods defined by the class that is identified by classname in the current schema. It returns the number of methods successfully compiled. If the class does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION compile_class(classname VARCHAR2) return NUMBER;

compile_class

This function compiles all methods defined by the class that is identified by classname in the supplied schema. It returns the number of methods successfully compiled. If the class does not exist in the schema or the schema does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION compile_class(schema VARCHAR2,
classname VARCHAR2) return NUMBER;

uncompile_class

This function uncompiles all methods defined by the class that is identified by classname in the current schema. It returns the number of methods successfully uncompiled. If the value of the argument permanentp is nonzero, then mark these methods as permanently dynamically uncompilable. Otherwise, they are eligible for future dynamic recompilation. If the class does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION uncompile_class(classname VARCHAR2,
permanentp NUMBER default 0) return NUMBER;

uncompile_class

This function uncompiles all methods defined by the class that is identified by classname in the supplied schema. It returns the number of methods successfully uncompiled. If the value of the argument permanentp is nonzero, then mark these methods as permanently dynamically uncompilable. Otherwise, they are eligible for future dynamic recompilation. If the class does not exist in the schema or the schema does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION uncompile_class(schema VARCHAR2,
classname VARCHAR2,
permanentp NUMBER default 0) return NUMBER;

compile_method

This function compiles the method specified by name and Java type signatures defined by the class, which is identified by classname in the current schema. It returns the number of methods successfully compiled. If the class does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION compile_method(classname  VARCHAR2,
methodname VARCHAR2,
methodsig  VARCHAR2) return NUMBER;

compile_method

This function compiles the method specified by name and Java type signatures defined by the class that is identified by classname in the supplied schema. It returns the number of methods successfully compiled. If the class does not exist in the schema or the schema does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION compile_method(schema VARCHAR2,
classname  VARCHAR2,
methodname VARCHAR2,
methodsig  VARCHAR2) return NUMBER;

uncompile_method

This function uncompiles the method specified by the name and Java type signatures defined by the class that is identified by classname in the current schema. It returns the number of methods successfully uncompiled. If the value of the argument permanentp is nonzero, then mark the method as permanently dynamically uncompilable. Otherwise, it is eligible for future dynamic recompilation. If the class does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION uncompile_method(classname  VARCHAR2,
methodname VARCHAR2,
methodsig  VARCHAR2,
permanentp NUMBER default 0) return NUMBER;

uncompile_method

This function uncompiles the method specified by the name and Java type signatures defined by the class that is identified by classname in the supplied schema. It returns the number of methods successfully uncompiled. If the value of the argument permanentp is nonzero, then mark the method as permanently dynamically uncompilable. Otherwise, it is eligible for future dynamic recompilation. If the class does not exist in the schema or the schema does not exist, then an ORA-29532 (Uncaught Java exception) occurs.

FUNCTION uncompile_method(schema VARCHAR2,
classname  VARCHAR2,
methodname VARCHAR2,
methodsig  VARCHAR2,
permanentp NUMBER default 0) return NUMBER;

Configuring Memory Initialization Parameters

You can modify the following database initialization parameters to tune your memory usage to reflect your application needs more accurately:

• SHARED_POOL_SIZE

  Shared pool memory is used by the class loader within the JVM. The class loader, on an average, uses about 8 KB of memory for each loaded class. Shared pool memory is used when loading and resolving classes into the database. It is also used when compiling the source in the database or when using Java resource objects in the database.

  The memory specified in SHARED_POOL_SIZE is consumed transiently when you use loadjava. The database initialization process requires SHARED_POOL_SIZE to be set to 96 MB because it loads the Java binaries for approximately 8,000 classes and resolves them. The SHARED_POOL_SIZE resource is also consumed when you create call specifications and as the system tracks dynamically loaded Java classes at run time.

• JAVA_POOL_SIZE

  Oracle JVM memory manager uses JAVA_POOL_SIZE mainly for in-memory representation of Java method and class definitions, and static Java states that are migrated to session space at end-of-call in shared server mode. In the first case, you will be sharing the memory cost with all Java users. In the second case, the value of JAVA_POOL_SIZE varies according to the actual amount of state held in static variables for each session. But, Oracle recommends the minimum value as 50 MB.

• JAVA_SOFT_SESSIONSPACE_LIMIT

  This parameter lets you specify a soft limit on Java memory usage in a session, which will warn you if you must increase your Java memory limits. Every time memory is allocated, the total memory allocated is checked against this limit.

  When a user's session Java state exceeds this size, Oracle JVM generates a warning that is written into the trace files. Although this warning is an informational message and has no impact on your application, you should understand and manage the memory requirements of your deployed classes, especially as they relate to usage of session space.

• JAVA_MAX_SESSIONSPACE_SIZE

  If a Java program, which can be called by a user, running in the server can be used in a way that is not self-limiting in its memory usage, then this setting may be useful to place a hard limit on the amount of session space made available to it. The default is 4 GB. This limit is purposely set extremely high to be normally invisible.

  When a user's session Java state attempts to exceeds this size, the application can receive an out-of-memory failure.

Java Pool Memory

Java pool memory is used in server memory for all session-specific Java code and data within the JVM. Java pool memory is used in different ways, depending on what mode Oracle Database server is running in.

Java Pool Memory Used within a Dedicated Server

The following is what constitutes the Java pool memory used within a dedicated server:

• The shared part of each Java class used per session.

  This includes read-only memory, such as code vectors, and methods. In total, this can average about 4 KB to 8 KB for each class.

• None of the per-session Java state of each session.

  For a dedicated server, this is stored in the User Global Area (UGA) within the Program Global Area (PGA), and not within the SGA.

Under dedicated servers, the total required Java pool memory depends on the applications running and may range between 10 and 50 MB.

Java Pool Memory Used within a Shared Server

The following is what constitutes the Java pool memory used within a shared server:

• The shared part of each Java class that is used per session.

  This includes read-only memory, such as vectors, and methods. In total, this can average about 4 KB to 8 KB for each class.

• Some of the UGA used for per-session state of each session is allocated from the Java pool memory within the SGA

  Because the Java pool memory size is fixed, you must estimate the total requirement for your applications and multiply by the number of concurrent sessions the applications want to create, to calculate the total amount of necessary Java pool memory. Each UGA grows and shrinks as necessary. However, all UGAs combined must be able to fit within the entire fixed Java pool space.

Under shared servers, this figure could be large. Java-intensive, multiuser benchmarks could require more than 100 MB.

Displaying Used Amounts of Java Pool Memory

You can find out how much of Java pool memory is being used by viewing the V$SGASTAT table. Its rows include pool, name, and bytes. Specifically, the last two rows show the amount of Java pool memory used and how much is free. The total of these two items equals the number of bytes that you configured in the database initialization file.

SVRMGR> select * from v$sgastat;

POOL        NAME                            BYTES
----------- -------------------------- ----------
            fixed_sga                       69424
            db_block_buffers              2048000
            log_buffer                     524288
shared pool free memory                  22887532
shared pool miscellaneous                  559420
shared pool character set object            64080
shared pool State objects                   98504
shared pool message pool freequeue         231152
shared pool PL/SQL DIANA                  2275264
shared pool db_files                        72496
shared pool session heap                    59492
shared pool joxlod: init P                   7108
shared pool PLS non-lib hp                   2096
shared pool joxlod: in ehe                4367524
shared pool VIRTUAL CIRCUITS               162576
shared pool joxlod: in phe                2726452
shared pool long op statistics array        44000
shared pool table definiti                    160
shared pool KGK heap                         4372
shared pool table columns                  148336
shared pool db_block_hash_buckets           48792
shared pool dictionary cache              1948756
shared pool fixed allocation callback         320
shared pool SYSTEM PARAMETERS               63392
shared pool joxlod: init s                   7020
shared pool KQLS heap                     1570992
shared pool library cache                 6201988
shared pool trigger inform                  32876
shared pool sql area                      7015432
shared pool sessions                       211200
shared pool KGFF heap                        1320
shared pool joxs heap init                   4248
shared pool PL/SQL MPCODE                  405388
shared pool event statistics per sess      339200
shared pool db_block_buffers               136000
java pool   free memory                  30261248
java pool   memory in use                19742720
37 rows selected.

Correcting Out of Memory Errors

If you run out of memory while loading classes, then it can fail silently, leaving invalid classes in the database. Later, if you try to call or resolve any invalid classes, then a ClassNotFoundException or NoClassDefFoundException instance will be thrown at run time. You would get the same exceptions if you were to load corrupted class files. You should perform the following:

• Verify that the class was actually included in the set you are loading to the server.

• Use the loadjava -force option to force the new class being loaded to replace the class already resident in the server.

• Use the loadjava -resolve option to attempt resolution of a class during the load process. This enables you to catch missing classes at load time, rather than at run time.

• Double check the status of the newly loaded class by connecting to the database in the schema containing the class, and run the following:

  SELECT * FROM user_objects WHERE object_name = dbms_java.shortname('');
  

  The STATUS field should be VALID. If loadjava complains about memory problems or failures, such as lost connection, then increase SHARED_POOL_SIZE and JAVA_POOL_SIZE, and try again.