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:
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