10 Oracle Database Java Application Performance

10.1.1 Accelerator Overview

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

Figure 10-1 Native Compilation Using Accelerator

Given a JAR file, the Accelerator performs the following:

1. Verifies the classes that are loaded in the database.

2. Retrieves the Java bytecodes for these classes from the database and stores them in a project directory where the Accelerator was invoked.

3. Translates the Java bytecodes to C code.

4. Compiles and links the C code using the C compiler for your platform.

   The Accelerator translates, compiles, and links the retrieved classes on the client. For this reason, you must natively compile on the intended platform environment to which this application will be deployed. 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 Accelerator natively compiled libraries can be used only within Oracle Database. Also, these libraries can only be used within the same version of Oracle Database in which it was produced. 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.

10.1.2 Oracle Database Core Java Class Libraries

All core Java class libraries and Oracle-provided Java code within Oracle Database 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, orajox10java_lang.so on Solaris and orajox10java_lang.dll on Windows NT hold java.lang classes. Specifics of packaging and naming can vary by platform. The OracleJVM uses natively compiled Java files internally and opens them, as necessary, at runtime.

10.1.3 Natively Compiling Java Application Class Libraries

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

10.1.4 Executing Accelerator

The following sections show how to do basic native compilation using Accelerator.

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

ncomp -user scott/tiger pubProject.JAR

If you change any of the classes within this JAR file, 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—execute ncomp with the -force option, as follows:

ncomp -user scott/tiger -force pubProject.JAR

10.1.5 ncomp

Accelerator, implemented within the ncomp tool, natively compiles all classes within the specified JAR, ZIP, or list of classes. Accelerator natively compiles these classes and places them into shared libraries according to their package. Note that these classes must first be loaded into the database.

If the classes are designated within a JAR file and have already been loaded in the database, you can natively compile your Java classes by executing the following:

ncomp -user SCOTT/TIGER myClasses.jar

There are options that allow you control over how the details of native compilation are handled.

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]

{-user | -u} <user>/<password>[@<database>]

10.1.6 Native Compilation Usage Scenarios

The following scenarios demonstrate how you can use each of the options for the ncomp tool can be used:

• Natively Compiling on Test Platform—Java Classes Already Loaded in the Database

• Natively Compiling Java Classes Not Loaded in the Database

• Clean Compile and Generate Output for Future Deployment

• Controlling Native Compilation Build Environment

• Natively Compiling Specific Classes

• Natively Compiling Packages That Are Fully or Partially Modified

ncomp -user SCOTT/TIGER pubProject.jar

ncomp -user SCOTT/TIGER@dbhost:5521:orcl -thin -load pubProject.jar

ncomp -user SCOTT/TIGER -force -outputJarFile pubworks.jar pubProject.jar

ncomp -user SCOTT/TIGER -projectDir /tmp/jaccel/pubComped pubProject.jar

import com.myDomain.myPackage.*;

import com.myDomain.myPackage.mySubPackage.*;

import com.myDomain.myPackage.myClass;

import com.myDomain.myPackage.*;

import com.myDomain.hisPackage.hisSubPackage.*;

import com.myDomain.herPackage.herClass;

import com.myDomain.petPackage.petClass;

ncomp -user SCOTT/TIGER /tmp/jaccel/pubComped/pubworks.classes

ncomp -user scott/tiger -force pubProject.JAR

10.1.7 deploync

You can deploy any deployment JAR file with the deploync command. This includes the default output JAR file, <file>_depl.jar or the JAR created when you used the ncomp -outputJarFile option. The operating system and Oracle Database version must be the same as the platform where it was natively compiled.

deploync [options] <deployment>.jar

  -user | -u <username>/<password>[@<database_url>]

  [-projectDir | -d <project_directory>]

  [-thin]

  [-oci | -oci8]

deploync -user SCOTT/TIGER@dbhost:5521:orcl -thin /tmp/jaccel/PubComped/pub.jar

10.1.8 statusnc

After the native compilation is completed, you can check the status for your Java classes through the statusnc command. This tool will print out—either to the screen or to a designated file—the status of each class. In addition, the statusnc tool always saves the output within the JACCELERATOR$STATUS table. The values can be the following:

statusnc [ options ] <class_designation_file>

   -user <user>/<password>[@database]

   [-output | -o <filename>]

   [-projectDir | -d <directory>]

   [-thin]

   [-oci | -oci8]

statusnc -user SCOTT/TIGER -output pubStatus.txt /tmp/jaccel/PubComped/pub.jar

10.2.1 Configuring Memory Initialization Parameters

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

• SHARED_POOL_SIZE—Shared pool memory is used by the class loader within the JVM. The class loader uses an average of about 8 KB for each loaded class. Shared pool memory is used when loading and resolving classes into the database. It is also used when compiling 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 (executing initjvm.sql against a clean database, as opposed to the installed seed database) requires SHARED_POOL_SIZE to be set to 50 MB as 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 runtime.

• JAVA_POOL_SIZE—The OracleJVM memory manager allocates all other Java state during runtime execution from the amount of memory allocated using JAVA_POOL_SIZE. This memory includes the shared in-memory representation of Java method and class definitions, as well as the Java objects migrated to session space at end-of-call. In the first case, you will be sharing the memory cost with all Java users. In the second case, in a shared server, you must adjust JAVA_POOL_SIZE allocation based on the actual amount of state held in static variables for each session. See "Java Pool Memory" for more information on JAVA_POOL_SIZE.

• JAVA_SOFT_SESSIONSPACE_LIMIT—This parameter allows you to 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-duration Java state exceeds this size, OracleJVM generates a warning that is written into the trace files. While this warning is simply 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 user-invokable Java program executing in the server can be used in a way that is not self-limiting in its memory usage, 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-duration Java state attempts to exceeds this size, your application can receive an out-of-memory failure.

Oracle Database's unique memory management facilities and sharing of read-only artifacts (such as bytecodes) enables HelloWorld to execute with a per-session incremental memory requirement of only 35 KB. More stateful server applications have a per-session incremental memory requirement of approximately 200 KB. Such applications must retain a significant amount of state in static variables across multiple calls. Refer to the discussion in the "End-of-Call Migration" section for more information on understanding and controlling migration of static variables at end-of-call.

10.2.1.1 Initializing Pool Sizes within Database Templates

You can set the defaults for JAVA_POOL_SIZE and SHARED_POOL_SIZE in the database installation template. The Database Configuration Assistant (DBCA) allows you to modify these values within the Memory section, as shown below in Figure 10-2.

Figure 10-2 Configuring OracleJVM Memory Parameters

10.2.2 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 the 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-8 KB for each class.

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

  For a dedicated server, this is stored in UGA within the PGA—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-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 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, multi-user benchmarks could require more than 100 MB.

10.2.3 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.

10.2.4 Correcting Out of Memory Errors

If you run out of memory while loading classes, it can fail silently, leaving invalid classes in the database. Later, if you try to invoke or resolve any invalid classes, you will see ClassNotFoundException or NoClassDefFoundException exceptions being thrown at runtime. 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. Many people have accidently forgotten to load just one class out of hundreds and spend considerable time chasing this down.

• 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 allows you to catch missing classes at load time, not run time.

• Double check the status of a newly loaded class by connecting to the database in the schema containing the class, and execute 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 "connection lost", increase SHARED_POOL_SIZE and JAVA_POOL_SIZE, and try again.