JVM Tutorials - Herong's Tutorial Examples
Dr. Herong Yang, Version 4.10

Testing with LongSleep.java

This section provides a tutorial example on how to run LongSleep.java with JRockit 8.0 and compare it with HotSpot.

Since my LongWhile is very CPU intensive (99% on Windows), which could be a critical factor for any JVM to manage. I decided to try JRockit JVM with a relative easy program, LongSleep.java:

/**
 * LongSleep.java
 * Copyright (c) 2003 by Dr. Herong Yang, herongyang.com
 */
class LongSleep {
   public static void main(String[] a) {
      Runtime rt = Runtime.getRuntime();
      System.out.println(" Free memory: " + rt.freeMemory());
      System.out.println("Total memory: " + rt.totalMemory());
      try {Thread.sleep(1000*60*60);} 
      catch (InterruptedException e) {}
   }
}

Test 5: Running LongSleep with JRockit

I compiled LongSleep with the compiler command interface provided by JRockit, then launched it with JRockit JVM:

\local\bea\JRockit80_141_32\bin\java LongSleep
 Free memory: 66936968
Total memory: 77594624

On the Windows Task Manager:

Before running LongWhile:
   Performance tab:      CPU:   1%, MEM: 133052K

Once LongSleep started:
   Performance tab:      CPU:   1%, MEM: 231660K
   Processes tab - java: CPU:   0%, MEM:  10988K

10 minutes later: about the same.

Again, nothing un-usual, except for the difference of the memory usages reported by JRockit JVM and Windows Task Manager: 77594K vs. 10988K.

Test 6: Running LongSleep with HotSpot

For comparison purposes, I launched LongSleep with HotSpot JVM:

\local\j2sdk1.4.1_01\bin\java LongSleep
 Free memory: 1781480
Total memory: 2031616

On the Windows Task Manager:

Before running LongWhile:
   Performance tab:      CPU:   1%, MEM: 133052K

Once LongSleep started:
   Performance tab:      CPU:   1%, MEM: 141424K
   Processes tab - java: CPU:   0%, MEM:   4716K

10 minutes later: about the same.

Results looked ok.

Test 7: Running LongSleep with JRockit plus Management

Now, back to JRockit, but with Management option turned on this time:

\local\bea\jrockit80_141_32\bin\java -Xmanagement LongSleep
[JRockit] Management Server started on port 7090.
 Free memory: 66912936
Total memory: 77594624

On the Windows Task Manager:

Before running LongWhile:
   Performance tab:      CPU:   1%, MEM: 132032K

Once LongWhile started:
   Performance tab:      CPU:   1%, MEM: 233220K
   Processes tab - java: CPU:   0%, MEM:  12852K

10 minutes later: about the same.

Results looked ok too.

Test 8: Running LongSleep and JRockit Management Console Client

In this final test, I want to run JRockit management console client, connecting to my LongSleep running under JRockit JVM. So I started LongSleep first, then launched the management console client program:

cd \local\bea\jrockit80_141_32\console\client
..\..\bin\java -jar ManagementConsole.jar

The client program started ok. I had no problem connecting the client program to the console server that was running with my LongSleep. The connection was stable this time, but there was a different problem, see my records bellow:

On Windows Task Manager - Before running LongWhile:
   Performance tab:      CPU:   1%, MEM: 132032K

On Windows Task Manager - Once LongWhile started:
   Performance tab:      CPU:   1%, MEM: 211088K
   Processes tab - java: CPU:   0%, MEM:  12872K

On Windows Task Manager - Once Management Console Client started:
   Performance tab:      CPU: 24-35%, MEM: 358072K
   Processes tab - java: CPU:     4%, MEM:  19520K - LongSleep
   Processes tab - java: CPU: 21-31%, MEM: 116452K - Console Client

4 minutes later:
   Performance tab:      CPU: 24-35%, MEM: 358692K
   Processes tab - java: CPU:     4%, MEM:  22320K - LongSleep
   Processes tab - java: CPU: 21-31%, MEM: 129128K - Console Client

4 minutes later:
   Performance tab:      CPU: 24-35%, MEM: 358588K
   Processes tab - java: CPU:     4%, MEM:  26312K - LongSleep
   Processes tab - java: CPU: 21-31%, MEM: 129296K - Console Client

10 minutes later:
   Windows crashed with dialog box saying:
      "winlogon.exe - Application Error"

A couple of interesting things to be noted here:

  • I repeated the test, and got similar results.
  • The crash seems to be related to my screen saver, which was set to the Windows logon dialog box. I guess I could turn off my screen saver to avoid this crash.
  • There was a slow increase of memory usages on both java instances: LongSleep and Console Client.
  • The CPU usage was oscillating during the test. My guess was that the console client program was pulling information out of the console server with a fixed sampling interval.

On the memory tab of the console client program, I also noticed that the "used mem" number was going up, while the "free mem" number was going down. At one time, I recorded the following numbers:

ocillation is espected because of sampling...
 used heap 11139,  used mem: 295516
 free heap 64620,  free mem: 226628
total heap 75776, total mem: 522467

Last update: 2003.

Table of Contents

 About This Book

 Download and Install Java SE 1.6 Update 2

 java.lang.Runtime Class - The JVM Instance

 java.lang.System Class - The Operating System

 ClassLoader Class - Class Loaders

 Class Class - Class Reflections

 Sun's JVM - Java HotSpot VM

 JRockit JVM 7.0 by BEA Systems

JRockit JVM 8.0 by BEA Systems

 Installing JRockit JVM 8.0

 Testing with LongWhile.java

Testing with LongSleep.java

 Memory Management Rules and Tests

 Garbage Collection Tests

 Stack Overflow Tests

 Thread Testing Program and Result

 StringBuffer Testing Program and Result

 CDS (Class Data Sharing)

 Micro Benchmark Runner and JVM Options

 Micro Benchmark Tests on "int" Operations

 Micro Benchmark Tests on "long" Operations

 Micro Benchmark Tests in JIT Compilation Mode

 Micro Benchmark Tests on "float" and "double" Operations

 References

 PDF Printing Version

Dr. Herong Yang, updated in 2010
Testing with LongSleep.java