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 3: Running LongWhile with JRockit plus Management

In this test, I wanted to see what's the impact of running JRockit with the Management option turned on:

\local\bea\jrockit80_141_32\bin\java -Xmanagement LongWhile
[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: 100%, MEM: 231876K
   Processes tab - java: CPU:  99%, MEM:  12582K

10 minutes later: about the same.

The Management option only increased the memory usage by about 2MB, comparing to Test 1.

Test 4: Running LongWhile and JRockit Management Console Client

In this test, I wanted to repeat the same test I did with JRockit 7.0, see my notes on JRockit 7.0. In that test, I observed that the Management Console Client crashed immediately on my laptop with 128MB RAM. It also crashed on my desktop with 256MB RAM with a slow memory leak.

This test was done on my desktop, which had been upgraded to 512MB RAM recently. I started JRockit JVM with my LongWhile program first, then launched the Management Console client program:

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

The console client program took about 1 minute to get fully started. Then I tried to connect to the console server that was running with my LongWhile. But the connection was closed immediately by the server. Here is what I recored:

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

On Windows Task Manager - Once LongWhile started:
   Performance tab:      CPU: 100%, MEM: 231968K
   Processes tab - java: CPU:  99%, MEM:  12520K

On Windows Task Manager - Once Management Console Client started:
   Performance tab:      CPU: 100%, MEM: 372284K
   Processes tab - java: CPU:  99%, MEM:  12520K - LongWhile
   Processes tab - java: CPU:   0%, MEM:  62996K - Console Client

On Console Client - Tried to connect to the Console Server:
   The Console Client worked for about 10 seconds. 
   A dialog box showed up: "Connection lost to JRockit Management ..."

On the LongWhile running window:
   [JRockit] New Management Server connection from 127.0.0.1
   [JRockit] Management Server connection closed.

I repeated the test again, and got the same results. So what could be the reasons for this problem? My guesses are:

• My Windows system was not good for JRockit 8.0. I was running Windows 2000 with Service Pack 2.
• My test program, LongWhile, is too tough to be supported by the Management Console.
• I wasn't using JRockit correctly.

Testing with LongSleep.java

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
 */
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.

(Continued on next part...)

Part:   1  2  3 

This site Web