Herong's Tutorial Notes on JVM
Dr. Herong Yang, Version 3.00, 2007

JRockit JVM 8.0

Part:   1  2  3 

This chapter explains:

  • Installing JRockit JVM 8.0
  • Testing with LongWhile.java
  • Testing with LongSleep.java

(Continued from previous part...)

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 LongWhile. 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

Part:   1  2  3 

Dr. Herong Yang, updated in 2007
Herong's Tutorial Notes on JVM - JRockit JVM 8.0