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

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

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

Last update: 2003.

Table of Contents

 About This Book

 Downloading and Installing JDK 1.8.0 on Windows

 Downloading and Installing JDK 1.7.0 on Windows

 java.lang.Runtime Class - The JVM Instance

 java.lang.System Class - The Operating System

 ClassLoader Class - Class Loaders

 Class Class - Class Reflections

 Sun's JVM - Java HotSpot VM

 JRockit JVM 28.2.7 by Oracle Corporation

 JVM Runtime Data Areas

 Memory Management and Garbage Collectors

 Garbage Collection Tests

 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

Outdated Tutorials

 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

 Outdated: Running JRockit JVM with Management Console

 References

 PDF Printing Version