JVM Tutorials - Herong's Tutorial Examples - v5.11, by Dr. Herong Yang
Outdated: Testing with LongWhile.java
This section provides a tutorial example on how to run LongWhile.java with JRockit 8.0 and compare it with HotSpot.
Here is my LongWhile.java I used before to test the previous version of JRockit:
/** * LongWhile.java * Copyright (c) 2002, HerongYang.com, All Rights Reserved. */ class LongWhile { public static void main(String[] a) { Runtime rt = Runtime.getRuntime(); System.out.println(" Free memory: " + rt.freeMemory()); System.out.println("Total memory: " + rt.totalMemory()); while (true); } }
Test 1: Running LongWhile with JRockit
I compiled LongWhile with the compiler command interface provided by JRockit, then launched it with JRockit JVM:
\local\bea\JRockit80_141_32\bin\java LongWhile Free memory: 66936968 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: 230468K Processes tab - java: CPU: 99%, MEM: 10740K 10 minutes later: about the same.
So, everything looked normal. But one interesting area was that the memory usages reported by JRockit JVM and Windows Task Manager were very different: 77594K vs. 10740K.
Test 2: Running LongWhile with HotSpot
In order to compare with HotSpot, I repeated above test with J2SDK 1.4.1_01:
\local\j2sdk1.4.1_01\bin\java LongWhile Free memory: 1782304 Total memory: 2031616
On the Windows Task Manager:
Before running LongWhile: Performance tab: CPU: 1%, MEM: 132032K Once LongWhile started: Performance tab: CPU: 100%, MEM: 140960K Processes tab - java: CPU: 99%, MEM: 4716K 10 minutes later: about the same.
Obviously, the memory usage reported by HotSpot matched better with Windows Task Manager: 2031K vs. 4716K. The difference here reflected the memory usage of the JVM itself.
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 recorded:
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:
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
Outdated: Download and Install JDK 1.8.0 on Windows
Outdated: Download and Install JDK 1.7.0 on Windows
Outdated: Download and Install Java SE 1.6 Update 2
Outdated: Installing JRockit JVM 8.0
►Outdated: Testing with LongWhile.java
Outdated: Testing with LongSleep.java
Outdated: GCTest.java - Garbage Collection Test Program
Outdated: GC Test - Constant Memory Requirement
Outdated: GC Test - Periodical Memory Requirement
Outdated: GC Test - Releasing Old vs. New Objects
Outdated: GC Test - JDK 1.4.0 vs. JDK 1.3.1
Outdated: GC Test - Client vs. Server
Outdated: StringBuffer Testing Program
Outdated: Installing JRockit JVM 7.0