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

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

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

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

herong> cd \local\bea\jrockit80_141_32\console\client
herong> ..\..\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

 About This Book

 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 Runtime Data Areas

 JVM Stack, Frame and Stack Overflow

 Thread Testing Program and Result

 CPU Impact of Multi-Thread Applications

 I/O Impact of Multi-Thread Applications

 CDS (Class Data Sharing)

 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

 OpenJ9 by Eclipse Foundation

 JRockit JVM 28.2.7 by Oracle Corporation

Archived Tutorials

 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

 Archived: Running JRockit JVM with Management Console

 References

 Full Version in PDF/EPUB