ISTEK Consulting - Java and CICS

Background
When IBM first introduced Java on the mainframe, its performance was so atrocious that it had to provide a native code compiler called HPJ to actually make any of the applications run reasonably under zOS. In the last 5 years, IBM made tremendous improvements to Java performance and HPJ is no longer supported. However, without HPJ, the IBM JVM designers had to solve another problem that was a huge performance bottleneck - JVM startup costs. This problem was insurmountable in the transaction environments such as CICS and DB2 Stored Procedures due to the underlying architecture of those products. Unlike Websphere, which maintains a pool of JVMs and multi-threads transactions through this pool, both CICS and DB2 started a new copy of a JVM for each invocation. This made any kind of high throughput application impossible.

Introducing the PR JVM
To solve the initialization problem, IBM designed a new JVM which they called the Persistent Reusable JVM. The main feature of the new design split the JVM heap into multiple areas. The system heap was where classes and internal data structures were held. The trusted middleware heap held classes and data that could persist across transactions. The application heap would contain transaction specific data. At the end of the transaction, instead of tearing down the JVM and building a new one for the next transaction, CICS would just wipe out the application heap. Only under certain, rare occurances, would the entire JVM be rebuilt. The new design significantly improved the steady state throughput of CICS Java transactions, but still did not address the high startup cost issues.

The Master and the Slave
The high startup costs of the CICS regions is explained by the design of the JVM pools in CICS. Each region is defined with a certain number of JVMs that it will create as transactions flow into the region. This pool then is reused for subsequent transactions. So, if the startup cost of a JVM is 2 seconds, and there are 5 JVMs defined to a region, the first 5 transactions will each take at least 2 seconds to start up. In order to further help the initialization performance, IBM introduced the notion of a Master JVM whose main job it is to hold a shared memory classcache. Any transactions are actually dispatched to Worker JVMs which are cloned from the Master. The initialization of a Worker is much quicker since it doesn't need to load the classes in order to start running.

Continuous Mode JVMs One of the problems with a reusable JVM is the fact that when the transaction ends, all the transaction data is wiped out. This is really bad if you have static data which you'd like to persist across transactions. This is similar to Shared Data Tables in CICS, but even more powerful, since you can actually store complex object graphs in memory. You could put the objects in the trusted middleware heap, but this introduces some complexity. Furthermore, we found that the JDBC drivers had some problems when code was in the trusted middleware heap. With CICS TS 2.3, IBM introduced a continuous mode JVM. Essentially, this is a conventional JVM which does not reset itself after every transaction. The programmer is responsible for managing the data in the heap. However, this allows objects to be shared across transactions which can be a very big performance boost for the application.

Background	When IBM first introduced Java on the mainframe, its performance was so atrocious that it had to provide a native code compiler called HPJ to actually make any of the applications run reasonably under zOS. In the last 5 years, IBM made tremendous improvements to Java performance and HPJ is no longer supported. However, without HPJ, the IBM JVM designers had to solve another problem that was a huge performance bottleneck - JVM startup costs. This problem was insurmountable in the transaction environments such as CICS and DB2 Stored Procedures due to the underlying architecture of those products. Unlike Websphere, which maintains a pool of JVMs and multi-threads transactions through this pool, both CICS and DB2 started a new copy of a JVM for each invocation. This made any kind of high throughput application impossible.
Introducing the PR JVM	To solve the initialization problem, IBM designed a new JVM which they called the Persistent Reusable JVM. The main feature of the new design split the JVM heap into multiple areas. The system heap was where classes and internal data structures were held. The trusted middleware heap held classes and data that could persist across transactions. The application heap would contain transaction specific data. At the end of the transaction, instead of tearing down the JVM and building a new one for the next transaction, CICS would just wipe out the application heap. Only under certain, rare occurances, would the entire JVM be rebuilt. The new design significantly improved the steady state throughput of CICS Java transactions, but still did not address the high startup cost issues.
The Master and the Slave	The high startup costs of the CICS regions is explained by the design of the JVM pools in CICS. Each region is defined with a certain number of JVMs that it will create as transactions flow into the region. This pool then is reused for subsequent transactions. So, if the startup cost of a JVM is 2 seconds, and there are 5 JVMs defined to a region, the first 5 transactions will each take at least 2 seconds to start up. In order to further help the initialization performance, IBM introduced the notion of a Master JVM whose main job it is to hold a shared memory classcache. Any transactions are actually dispatched to Worker JVMs which are cloned from the Master. The initialization of a Worker is much quicker since it doesn't need to load the classes in order to start running.
Continuous Mode JVMs	One of the problems with a reusable JVM is the fact that when the transaction ends, all the transaction data is wiped out. This is really bad if you have static data which you'd like to persist across transactions. This is similar to Shared Data Tables in CICS, but even more powerful, since you can actually store complex object graphs in memory. You could put the objects in the trusted middleware heap, but this introduces some complexity. Furthermore, we found that the JDBC drivers had some problems when code was in the trusted middleware heap. With CICS TS 2.3, IBM introduced a continuous mode JVM. Essentially, this is a conventional JVM which does not reset itself after every transaction. The programmer is responsible for managing the data in the heap. However, this allows objects to be shared across transactions which can be a very big performance boost for the application.