Better run time performance

Before tuning run time performances, ensure that you’re using optimized class files. For example, programs compiled in debug mode are slower than programs compiled without debug information. Read Compile-time optimizations for details.

Run time performance are influenced by the memory. Operations made in memory without swapping to disk are better performing. Java tries to gain memory by periodically performing a cleaning procedure called Garbage Collector; during this procedure performance are slowed down. The more memory you provide to Java and isCOBOL, the more operations will be made in memory and Java will not invoke the Garbage Collector if enough memory is available.

No logging

Logging the Runtime activity to file has a cost in terms of disk i/o. If the Runtime must record every operation on a disk file, it will loose time doing it. Therefore, it’s strongly suggested to disable the isCOBOL logging by changing the configuration in one of the following three ways:

•	avoid having iscobol.tracelevel set in the configuration or

•	set iscobol.tracelevel=0 in the configuration or

•	put an hash sign before iscobol.tracelevel in the configuration file

More memory to Java

The JVM memory is controlled by three option:

-Xms	Set initial Java heap size (in bytes) The default size is 2097152 (2MB). The values must be a multiple of, and greater than, 1024 bytes (1KB). (The -server option increases the default size to 32M.)
-Xmx	Set maximum Java heap size (in bytes) The default size is 64M. (The -server option increases the default size to 128M.) The maximum heap limit is about 2 GB (2048MB).
-Xss	Set java thread stack size (in bytes) The default size is 256K.

For example, in order to specify a memory limit of 512 MB, you use:

iscrun -J-Xmx512m PROGRAM

It’s suggested to run on 64 bit systems, so the memory amount for Java can be increased over 2GB, that is the maximum amount of memory per process on 32 bit systems.

More memory to isCOBOL

isCOBOL can allocate more memory for arrays and sort works.

To provide more memory for array handling, set the property iscobol.array_cache in the isCOBOL configuration. Veryant recommends to set it to the maximum number of OCCURS in the application. If memory consumption is slowing performance then set to a lower value and in this case, a prime number is recommended to reduce collisions by making a more even hash distribution.

The default is 101. There is no maximum value, but higher values consume more memory.

To provide more memory for sorting procedures, set the property iscobol.sort.memsize in the isCOBOL configuration. Veryant recommends to increase the sort memory to a minimum value of 16 MB:

iscobol.sort.memsize=16000000

Class loading optimizations

Each time a new class is loaded into the JVM, a certain amount of time is spent to perform the necessary operations. While working with isCOBOL a new class is loaded each time a COBOL program is called the first time and each time a COBOL program uses a class (a runtime feature or an external Java class) that has not been loaded yet.

The class loading process can be optimized in two ways:

1.	Using the Java option

•	-Xverify:none

With this option you instruct the JVM to not verify the correctness of the bytecode. Avoiding such verification, the JVM loads the classes faster.

2.	Setting the CLASSPATH instead of iscobol.code_prefix to tell where your programs are stored.

When the code_prefix is set, the isCOBOL runtime perform some operations to find the class on disk and check if the class need to be reloaded or not. These operations have a cost. Letting Java load your programs as standard Java classes from the CLASSPATH makes the classes to be loaded faster. The disadvantage is that the classes descriptions are kept in memory so you can’t update a program by just replacing the class file while the COBOL application is running, you also need to close and restart the JVM (in thin client you need to restart the isCOBOL Server).

Having classes loaded from the CLASSPATH you can perform two additional improvements:

1.	store your classes in jar libraries instead of folders. See JAR Files and the Jar Utility for details.

2.	preload the jar libraries by calling the C$PRELOAD routine.

Additional JVM optimizations

Where available, you should think about using the following Java options:

•

-server

This option is usually available only with the JDK (the JRE doesn’t provide it). It causes Java to work in server mode instead of the default client mode. The server mode causes background operations (such as file i/o) to be better performing.

•	-Xnoclassgc

This option disables the garbage collection. By default the JVM unloads a class from memory when there are no live instances of that class left, but this can degrade performance. Turning off class garbage collection eliminates the overhead of loading and unloading the same class multiple times. If a class is no longer needed, the space that it occupies on the heap is normally used for the creation of new objects. However, if you have an application that handles requests by creating a new instance of a class and if requests for that application come in at random times, it is possible that when the previous requester is finished, the normal class garbage collection will clean up this class by freeing the heap space it occupied, only to have to re-instantiate the class when the next request comes along. In this situation you might want to use this option to disable the garbage collection of classes.

With the JVM provided by IBM, the following option can also be used:

•	-Xshareclasses

This option make classes shared between JVM processes. This feature improves performance since class byte code needs to be loaded only once. Class byte code is loaded into a shared cache. This cache is then accessed by multiple JVMs to run the class bytecode. Currently, in Windows and UNIX, a cache is implemented as a memory mapped file. Because the byte code is cached in a file, it reduces demand for memory. Every cache has a name. A JVM must attach itself to a cache to share classes from it. This is done using the -Xshareclasses argument. For example:

iscrun -J-Xshareclasses:name=myCache PROGRAM

When this command is run for the first time, a cache called myCache is created. Classes (core Java classes and application classes) are cached there. If another JVM is launched with the same command line, classes will be shared between processes. A cache lives beyond the life time of a JVM. It can be explicitly deleted. It is also deleted when the OS is rebooted.

Latest Java version

Oracle implements performance improvements in every new version of Java. For this reason it’s suggested to use the latest stable Java version available.