Outdated: Testing with LongSleep.java

JVM Tutorials - Herong's Tutorial Examples

∟Outdated: 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, HerongYang.com, All Rights Reserved.
 */
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:

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