Strobe for Java overview
Concepts and terminology
Before using Strobe for Java, it is helpful to become familiar with the following concepts and terminology:
- Measurement request: A measurement request specifies the parameters for measuring the performance of an application. When the application is active, Strobe begins a measurement session, an interval where it collects performance data about the application while it is executing. Strobe stores measurement data in a sample dataset, a file that contains the information collected during a single measurement session. Each measurement session corresponds to one sample dataset.
- Performance profile: After Strobe closes the sample dataset, you can use it to create the Performance Profile, a hierarchical series of reports that present the performance data collected during a measurement session. These reports show where and how the application spends its time during execution.
- Attribution: It identifies the methods that invoke service routines causing CPU time. Review the Attribution of CPU Execution Time report when Java methods are responsible for significant CPU use.
How Strobe for Java works?
Strobe for Java collects application performance information as a Java application executes. When measurement completes, Strobe organizes this information into the Strobe Performance Profile, a series of reports that show where and how time is spent during application execution, pinpointing possible areas for performance improvement.
- To initiate a connection with an MJE JVM, Strobe Session Manager uses five Strobe startup parameters. For more information about parameters, see Strobe-for-Java-parameters .
- Make sure that Strobe Session Manager and the MJE JVM are running on the same LPAR.
- For MJE to sample a JVM in the measured address space, JMX for the target JVM must be configured and available at the start of the Strobe measurement. This feature supports all JVM types supported by MJE up to four JVMs in any type of address space; batch JOB, STC, CICS, and IMS.
- A new Data Collector (MJE JAVA) is added to the Data Collectors panel in ISPF, and a new toggle (Collect Java Info) added on the iStrobe Measurement Form which causes the measurement task to initiate requests to the MJE JVM.
- Additional panels or pop ups can be used to select a maximum of four JVMs for MJE to sample in the target address space.
- For ADD QUEUED there will be no JVM to select as the target is not running at the time of the ADD request, so Strobe measurement will attempt to locate the JVM PID and use that on the requests to MJE when MJE JAVA is set to Y in ISPF or the Display Java Info is toggled On in iStrobe. For spawned address spaces having duplicate JOB names the Active Job Selection list panel in ISPF or the Display Active Jobs and Processes link must be used to determine which address space to select, or the one with the lowest ASID will be used.
- Since Java JMX cannot sample at the same rate(s) as Strobe, the target sample count for MJE is fixed at 1000 which may not always be reached depending on the Strobe Session Duration and Target Sample Size. Increasing the Session Duration increases the chances of MJE obtaining 1000 samples.
- The Strobe Log shows the requests being sent to MJE and MJE’s responses. Additional Strobe debugging messages can be enabled in the Strobe startup parameters, and an MJE debugging message level can be set in ISPF from the Other Parameters panel, but these are best left off unless requested by Customer Support.
- The MJE feature in Strobe can be started or stopped using a MODIFY command, but if the new MJE parameters are coded properly the default state will be started. Messages in the Strobe log accompany the MJE feature being started and stopped.
JVM Java target environment
The Java Virtual Machine is the runtime instance in which a Java application executes. When the Java bytecode is compiled, it can execute on the Java Virtual Machine (JVM). The JVM defines a set of specifications that enable Java programs to run on virtually any platform.
The following example shows the Java Virtual Machine and the process that takes place from source code to execution. The first part of the process is the compilation of the Java source code to Java bytecode. Then the JVM starts and takes the name of the class for the .class file. It is then loaded by the class loader which processes the bytecode stream and sends it to the byte code verifier.

The structure and the bytecode validity is checked and if it is in order, it is sent on to either the JIT compiler or the Java interpreter. The JIT compiler will compile the byte code to machine code and the method, when invoked, will be executing machine code. If the interpreter receives the byte code, it executes the code, and it is either processed by the hardware or trapped by the operating system and indirectly executed.