JVM Tutorials - Herong's Tutorial Examples - v5.13, by Herong Yang
Archived: 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:
herong> \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:
\herong> 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:
herong> \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:
herong> cd \local\bea\jrockit80_141_32\console\client herong> ..\..\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:
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
Table of Contents
JVM (Java Virtual Machine) Specification
Java HotSpot VM - JVM by Oracle/Sun
java.lang.Runtime Class - The JVM Instance
java.lang.System Class - The Operating System
ClassLoader Class - Class Loaders
Class Class - Class Reflections
JVM Stack, Frame and Stack Overflow
Thread Testing Program and Result
CPU Impact of Multi-Thread Applications
I/O Impact of Multi-Thread Applications
Micro Benchmark Runner and JVM Options
Micro Benchmark Tests on "int" Operations
Micro Benchmark Tests on "long" Operations
Micro Benchmark Tests in JIT Compilation Mode
Micro Benchmark Tests on "float" and "double" Operations
JRockit JVM 28.2.7 by Oracle Corporation
archived: Download and Install JDK 14 on macOS
Archived: Download and Install Latest JDK 10 on Windows
Archived: Download and Install JDK 1.8.0 on Windows
Archived: Download and Install JDK 1.7.0 on Windows
Archived: Download and Install Java SE 1.6 Update 2
Archived: Installing JRockit JVM 8.0
Archived: Testing with LongWhile.java
►Archived: Testing with LongSleep.java
Archived: GCTest.java - Garbage Collection Test Program
Archived: GC Test - Constant Memory Requirement
Archived: GC Test - Periodical Memory Requirement
Archived: GC Test - Releasing Old vs. New Objects
Archived: GC Test - JDK 1.4.0 vs. JDK 1.3.1
Archived: GC Test - Client vs. Server
Archived: StringBuffer Testing Program
Archived: Installing JRockit JVM 7.0