The JIT compiler is a replacement of the compilers that were used in the earlier versions of Oracle Database.

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.

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.

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.

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.

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.

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.

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.

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.

Java Memory Usage

The typical and custom database installation process furnishes a database that has been configured for reasonable Java usage during development. However, run-time use of Java should be determined by the usage of system resources for a given deployed application. Resources you use during development can vary widely, depending on your activity. The following sections describe how you can configure memory, how to tell how much System Global Area (SGA) memory you are using, and what errors denote a Java memory issue:

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 the loadjava tool. 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.

Initializing Pool Sizes within Database Templates

You can set the defaults for JAVA_POOL_SIZE and SHARED_POOL_SIZE in the database installation template.

Figure 9-1 illustrates how the Database Configuration Assistant enables you to modify these values in the Memory section.

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.

Note:

If you are compiling code on the server, rather than compiling on the client and loading to the server, then you might need a bigger JAVA_POOL_SIZE than the default 20 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.

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: