In this chapter, we first look at the Continuous Java virtual machine (JVM), and we describe it in detail. We look at the potential problems and the things that you must avoid that might impact performance. We recommend that you review Chapter 16, “Java applications using a Java virtual machine (JVM): improving performance,” of the CICS Performance Guide, SC34-6833-01, for good performance tips.

In this section, we discuss reusable JVM.

CICS has a small number of Task Control Blocks (TCBs), which it uses when running application programs. Of these, the Quasi Reentrant (QR) TCB is used to single thread the entire workload. At any point in time there can be a number of transactions running in a CICS region. Only one of these has use of the QR TCB at any time. If that application needs to pause for some reason, for example, when writing to a data set or waiting for a resource lock, CICS suspends it, which allows another applications to gain control of the QR TCB and carry out some work; therefore, CICS can serialize the execution of all the applications that it has concurrently running, which prevents the actions of one from interfering with those of any others.

This mechanism was developed for applications that are written in fully compiled languages, such as COBOL, PL/I, or C. However, the introduction of support for Java programs presented some additional challenges, which CICS has had to address.

Pure Java requires an execution environment provided by a JVM that is written for the operating system on which it runs. On z/OS, a JVM can sometimes issue blocking calls, such as MVS waits, which cause the TCB that is used by the JVM to go into a wait state. If a JVM was started on the QR TCB, then blocking calls causes the entire CICS workload to pause. To address this issue, CICS Transaction Server Version 1.3 introduced a new type of TCB known as the J8 TCB. CICS uses one of these for each JVM that it starts. At the same time, from CICS Transaction Server Version 2.3 there is a J9 TCB to be added. And CICS Transaction Server Version 3.2 keeps J8 TCB and J9 TCB to support Java workloads.

The JVM that CICS uses supports multithreaded applications. However, only one application can run in a JVM at any one time. More than one TCB can be used when a single CICS region must support multiple concurrent Java applications. In this way, a CICS region can have a single pool of J8 and J9 TCBs to support its Java workloads.

All new CICS transactions start on the QR TCB. If the transaction makes use of a Java program, then CICS switches to either a J8 or a J9 TCB and runs the program under the control of a JVM there. When the program terminates, or if it needs to access a CICS-managed resource, then CICS switches control back to the QR TCB for that piece of processing. In this way, the JVM can pause without interrupting the rest of the CICS workload, so serialization of access to CICS resources and the management of the start and end of all transactions occurs using the QR TCB.

There are significant CPU costs in starting and stopping a JVM, which are often greater than the costs that are incurred from running of an application within a JVM. If a JVM can be serially reused by a number of CICS programs, the overhead of starting and stopping the JVM is confined to the first and last program in the sequence and those in between gain significant performance benefits from this.

However, if a JVM is reused, the potential exists for one Java application program to leave around objects whose state can interfere with the successful execution of programs that later reuse the same JVM. EJBs are inherently self-contained and as such cannot leave state around after their execution. Individual Java applications, on the other hand, tend to treat the JVM where they run as something to which they have exclusive use. They might assume that the JVM is destroyed when the application finishes, and that all object instances, created during program execution, get removed as a result of the termination of the JVM. This assumption is not valid when a JVM is serially reused and side effects, resulting from objects remaining in the JVM’s storage heap following the termination of one application, might interfere with other applications that later reuse the same JVM.

To address this issue, the IBM Development Kit for z/OS, Java 2 Technology Edition (SDK) provides a JVM with a modified heap structure, and this JVM can be driven in an attempt to reset its storage areas between separate program invocations. You can configure CICS Transaction Server Version 2 to make use of this mechanism. Reset processing extends the operation of the JVM but does have some adverse effect on its performance characteristics.

Not all applications cause these problems and, for them, this reset processing is an unnecessary overhead. CICS Transaction Server Version 2.3 and the SDK 1.4.1 provide support for another JVM configuration, which offers the potential for reuse, but that places responsibility for reset processing onto the applications that run there. This provides significant performance benefits but does present opportunities for badly behaved programs to interfere with others that reuse the same JVM.

In CICS Transaction Server for z/OS, Version 3 Release 2, resettable JVMs, which were reset between each use, are no longer supported. Any Java programs that ran in resettable JVMs must be migrated to run in continuous JVMs. Resettable JVMs had the option REUSE=RESET in their JVM profiles (or the older option Xresettable=YES).

Although this process enforced serial isolation for programs running in the JVM, the time and CPU usage that is required for a JVM reset reduced the performance of a resettable JVM compared to the performance of a continuous JVM. Resettable JVMs were also incompatible with future versions of Java, whereas continuous JVMs are compatible with future versions of Java.

An application that is coded with attention to the state of the JVM and to the items in static storage can operate safely in a continuous JVM without the JVM reset. If you need to police the use of any APIs in the continuous JVM, you can use the Java security manager to do this.

The migration process for Java programs that run in a resettable JVM involves checking that the Java programs do not contain any code that might have an unwanted effect on serial isolation when the continuous JVM is reused by a subsequent program. The CICS JVM Application Isolation Utility, a code checking and reporting utility, is provided with CICS Transaction Server for z/OS, Version 3 Release 2 to help identify areas where you must check the behavior of Java programs that were designed to run in resettable JVMs.

Configuration and tuning for continuous JVMs is simpler than it was for resettable JVMs. Your choice of class path is more straightforward, and there are fewer storage settings to tune. When you migrate an application to run in a continuous JVM, you probably need to merge some of your existing storage settings. Your existing class path options are accepted for migration purposes, and CICS issues a warning message about those options that are obsolete. [Reference: Java Applications in CICS Version 3 Release 2, SC34-6825-01.]

In this section, we discuss the Shared Class Cache facility. We begin by providing an overview of the Shared Class Cache and then we describe the benefits of using it.

The principle of sharing loaded classes between Java virtual machine (JVM) processes is not new. Actually the SDK V1.4 provided a mechanism that allows Java classes to be cached centrally and shared between different JVMs. Also, CICS Transaction Server Version 2.3 introduces a Shared Class Cache facility that extends this function to some, or all, of the JVMs that it controls.

Now CICS Transaction Server for z/OS, Version 3 Release 2 supports the JVM provided by the 31-bit version of IBM SDK for z/OS, Java 2 Technology Edition, Version 5, as an alternative to the JVM provided by Version 1.4.2 of the SDK. You can choose to migrate some or all of your CICS regions from Java 1.4.2 to Java 5 to benefit from the new Java language features, and also the improvements to execution technology in the IBM SDK for z/OS, V5, including improved garbage collection and simpler class sharing. [Reference: Java Applications in CICS Version 3 Release 2, SC34-6825-01.]

The new Shared Classes feature in the IBM implementation of version 5.0 of the Java platform offers a completely transparent and dynamic means of sharing all loaded classes that places no restrictions on the JVMs that share the class data. This feature offers a straightforward and flexible solution for reducing virtual memory footprint and improving startup time, and there are few applications that will not benefit from it. In this section, we explore how the feature works, how to use it, and when to use it, along with some of the features that it provides.

The feature in the IBM z/OS 1.4.2 JVM used a master JVM to populate a class cache that was then shared by worker JVMs, but the master/worker mechanism is replaced in the 5.0 JVM. In the 5.0 JVM, no JVM owns the cache, and there is no master/subordinate JVM concept; instead, any number of JVMs can read and write to the cache concurrently. The IBM implementation of the 5.0 JVM takes the concept a step further by allowing all system and application classes to be stored in a persistent dynamic class cache in shared memory. This Shared Classes feature is supported on all of the platforms on which the IBM implementation of the JVM ships. Figure 9-1 shows a view of the Shared Class Cache.

The Shared Classes feature was designed from the ground up to be an option that you can just switch on and forget about, yet it provides very powerful scope for reducing virtual memory footprint and improving JVM startup time. For this reason, it is best suited to environments where more than one JVM is running similar code or where a JVM is regularly restarted. [Reference: http://www.ibm.com/developerworks/java/library/j-ibmjava4/#4]

You enable class sharing by adding -Xshareclasses[:name=<cachename>] to an existing Java command line. When the JVM starts up, it looks for a class cache of the name given (if no name is provided, it chooses a default name), and it either connects to an existing cache or creates a new one, as required.

You specify cache size using the parameter -Xscmx<size>[k|m|g], which only applies if the JVM creates a new cache. If this option is omitted, a platform-dependent default value is chosen (typically 16 MB). Note that there are operating system settings that can limit the amount of shared memory to allocate. For z/OS, because the virtual address space of a process is shared between the shared class cache and the Java heap, increasing the maximum size of the Java heap reduces the size of the shared class cache that you can create.

The Shared Class Cache facility offers a number of benefits to clients. Java classes are loaded once per CICS region rather than once per JVM, which reduces the class loading overhead of each JVM startup in JVM ships. It also reduces the overall storage requirement for the JVM ships by storing a persistent dynamic class cache in shared memory, instead of one in each JVM’s storage heap.

In this section, we review potential problems and things you must avoid that can impact performance. These include:

JVM has to restart.

Use the Shareable classpath; otherwise, classes are physically reloaded each time.

Make sure heaps are big enough for 101 trans when CICS does GC anyway.

If a JVM is required to execute a Java program, CICS chooses to reuse a JVM that is not currently in use but initialized with the same JVM profile as the new request.

If no such JVM is available and the CICS region is not a MAXJVMTCB, CICS attaches a new J8 TCB and initializes a new JVM.

If no such JVM is available and the CICS region is at MAXJVMTCB, CICS steals a currently unused JVM, as shown in Figure 9-2 on page 226. Because this JVM is not using the same profile, it must be reinitialized.

If all of the MAXJVMTCB JVMs are being used, the new request must wait for a JVM to become available.

J8 TCBs that are used for Java do not come out of the MAXJVM pool. The JVM Pool is separate.

Class path is when we put our application programs on the Classpath and not the Shareable classpath. Figure 9-3 shows some classpath problems.

In this section, we provide brief points about excessive garbage collection.

Excessive garbage collection:

In this section, we describe the new IBM zSeries Application Assist Processor (zAAP), which you can configure on the IBM z990, z890, z9, and z10 servers. The zAAP is an attractively priced specialized processing unit that provides an economical Java execution environment for customers who want the traditional Qualities of Service and the integration advantages of the zSeries platform.

In the e-business on demand era, business requirements change more frequently than ever. To stay current and competitive, businesses are developing new strategic Web-based applications. Java adoption continues to accelerate as an open programming model, but these applications typically require more IT resources than traditional applications because levels of abstraction, code generation, and reuse. Unfortunately, IT budgets are not keeping pace with these needs, forcing customers to seek more cost effective and productive ways of to deploy new Java technology-based applications.

Using the zAAP optional assist feature you can purchase additional processing power exclusively for Java application execution without affecting the total MSU rating or machine model designation.

zAAPs are designed to operate asynchronously with the general CPs to execute Java programming under control of the IBM Java Virtual Machine (JVM). This is an important point because zAAPs can only help execute Java applications and application servers that use the IBM JVM. You can execute the IBM JVM processing cycles on the configured zAAPs with no modifications to the Java applications.

Using zAAPs you can:

When configured with general purpose processors within logical partitions that are running z/OS (or z/OS.e), zAAPs can help increase general purpose processor productivity and can contribute to lowering the overall cost of computing for z/OS Java technology-based applications.

The amount of general purpose processor savings vary based on the amount of Java application code that is executed by one or more zAAPs. This is dependent on the amount of Java cycles that the relevant applications use and on the zAAP execution mode that you select.

Execution of the Java applications on zAAPs, within the same z/OS LPAR as their associated database subsystems, can also help simplify the server infrastructures and improve operational efficiencies, for example, use of zAAPs can reduce the number of TCP/IP programming stacks, firewalls, and physical interconnections (and their associated processing latencies) that might otherwise be required when the application servers and their database servers are deployed on separate physical server platforms.

Hardware requirements for the zAAP are the z990, z890, z9, or z10 servers. On z990, z890, z9, or z10 servers, PUs characterized as zAAPs within a configuration are grouped into the ICF/IFL/zAAP processor pool. The ICF/IFL/zAAP processor pool appears on the hardware console as ICF processors. The number of ICFs shown is the sum of IFL, ICF, and zAAP processors that are characterized on the server.

zAAPs are designed to operate asynchronously with the general CPs to execute Java programming under the control of the IBM Java Virtual Machine (JVM). The IBM JVM processing cycles can be executed on the configured zAAPS with no anticipated modifications to the Java applications.

To exploit a zAAP, the operating system must be migrated to the following levels of software:

When a z/OS logical partition is configured, both CPs and zAAPs are defined as necessary to support the planned Java and non-Java workloads. zAAPs can be configured as initially online or reserved for subsequent use by z/OS as necessary. Pay attention that zAAPs cannot be IPLed, and at least one central processor is required for each z/OS partition.

zAAPs are defined as either shared by other logical partitions or dedicated to a specific partition; however, both central processors and the zAAPs for each partition have the same shared or dedicated attribute. For a given partition, you cannot define shared central processors and dedicated zAAPs or dedicated central processors and shared zAAPs. PR/SM configures shared zAAPs from the same pool of shared special purpose processors as ICFs and IFLs. Collectively, all shared ICFs, IFLs, and zAAPs also dynamically share in the processing requirements for all three special purpose processor types as controlled by PR/SM.

Integrated Facility for Applications (IFA) eligible work can run on both IFAs and standard processors. There are options that specify how the Java execution cycles are dispatched. You can specify that standard processors do not run any IFA-eligible work unless there are no IFAs operational in the partition. You can also prevent IFA-eligible work from running on standard processors because of software licensing considerations.

Figure 9-4 on page 230 shows the execution of a Java unit of work, as follows:

SDK1.4.1 has specific JVM options to handle zAAPs. However, if you are on z/OS V1R6 (or higher version) and want to enable zAAPs on your server, use the defaults. No additional setup is needed.

The JVM options for zAAP processing are:

Enables Java work to run on a zAAP if any zAAPs are available. This is the default. Only code written in Java and Java system native code is enabled to run on a zAAP. This design point is achieved in the Java support by requesting a switch to a zAAP for qualifying work and a switch request from a zAAP to a general purpose processor when non-qualifying work is encountered. This option is honored only with z/OS V1R6.

Disables the use of zAAPs.

Designed to estimate projected zAAP usage and write this information to STDOUT at intervals of n minutes. A value of 0 indicates that information is only written when Java terminates. The interval requested is not honored exactly. Messages are written after a switch is encountered for work that is considered eligible for off load to a zAAP or returning from that state. As a result, messages can be delayed during idle periods.

Designed to force Java to continue attempting to use zAAPs, even if none are available. This is typically specified for the purpose of collecting RMF/SMF data to assess potential zAAP use.