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