Resettable JVMs (REUSE=RESET)

The resettable JVM is kept in the JVM pool for reuse. The JVM is initialized once, and is reused many times. It can be reset to a known state between uses. A resettable JVM has the option REUSE=RESET in its JVM profile (or the older option Xresettable=YES).

The resettable JVM is normally reset between transactions; that is, after the application code has terminated for one transaction and before the application code starts for the next transaction. If more than one Java™ program is used in a transaction, the resettable JVM is reset after each Java program has completed. This level of reusability is equivalent to specifying the -Xresettable option for a JVM.

The JVM reset isolates invocations of Java programs from changes made by previous invocations of programs in the same JVM. This means that programs cannot create persistent items that might be of use to future executions of the same program, but it also means that programs cannot leave unwanted state in the JVM, or change the state of the JVM. However, the time and CPU usage required for a JVM reset reduce the performance of a resettable JVM compared to the performance of a continuous JVM. An application that has been coded with attention to the state of the JVM and to the items in static storage can operate safely without the JVM reset, so it can run in a continuous JVM to achieve performance enhancements.

There are two stages in the process of resetting a JVM:
  1. The resettable JVM checks whether there have been any unresettable events since the last reset of the JVM. A frequent cause of an unresettable event is that the Java program that just ran in the JVM has performed an unresettable action. An unresettable action is when a program uses Java interfaces that modify the state of a JVM in a way that cannot be properly reset, such as changing system properties or loading a native library. The Persistent Reusable Java Virtual Machine User's Guide, SC34-6201, has more information about unresettable actions. Another possible cause of an unresettable event is if a cross-heap reference in the JVM has been found, in the course of a trace-for-unresettability check, to be still in scope (rather than in garbage). Unresettable events can also occur if there is an error in the JVM code.

    If one or more unresettable events are detected during the execution of a user's Java program, the JVM is marked unresettable, and CICS destroys the JVM when the Java program has finished using it. The storage used by the JVM is recovered, and a new JVM is initialized. The events that prevent reuse are logged, provided that the appropriate event logging system properties are specified in the JVM properties file for the JVM.

    Middleware classes, that is, classes specified on the trusted middleware class path for the JVM, are permitted to perform unresettable actions without the JVM being marked unresettable. This is because they are trusted by the JVM to perform the actions necessary to reset themselves between transactions. You should use the application class paths for your own application classes, to ensure that if they do perform an unresettable action in a resettable JVM, the JVM is destroyed. Classes in a JVM explains more about the different classes and class paths in a JVM.

  2. A resettable JVM cleans up its storage heaps after each use, meaning that state cannot persist from one program invocation to the next. Storage heaps in a JVM explains the storage heaps that the JVM uses for different categories of objects. In a resettable JVM, the transient heap (which contains objects constructed by the user's application classes) is completely deleted during the reset, and the user's shareable application classes that are kept in the application-class system heap are reinitialized during the reset. The middleware heap, which contains objects constructed by the middleware classes, is not cleaned up by the JVM during the reset. Instead, the JVM requests the middleware classes to perform their own cleanup, and the middleware classes are trusted to reset the objects they have constructed.

A resettable JVM can use the shared class cache (that is, it can be a worker JVM). JVMs that use the shared class cache start up more quickly, and have lower storage requirements, than JVMs that do not.

Programming considerations for resettable JVMs explains the programming considerations for applications that run in a resettable JVM.