Startup Time Saving with Multiple JVM Processes

This section provides a tutorial example on how to save startup time by restoring shared archive 'java -Xshare:on'.

Based on the CDS feature document, some data will be shared by multiple JVM processes. To verify this, I am planning to run one JVM with, LongSleep.java:

/**
 * LongSleep.java
 * Copyright (c) 2010, 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) {}
   }
}

Then run my StartupTimeTest.pl while LongSleep is running to see the impact on the startup time.

In one command window:

\j2sdk1.5.0\bin\java -cp . -Xshare:on LongSleep
 Free memory: 1879152
Total memory: 2031616

In another command window:

perl StartupTimeTest.pl jdk150_on
Hello world!
Hello world!
...
Command: \j2sdk1.5.0\bin\java -cp . -Xshare:on Hello
Total time: 18 seconds.
Average time: 0.18 seconds.

As you can see from the test result, there is no saving on the start up time with multiple JVM processes. Can anyone help to explain why?

Steve Bohne from the CDS implementation team at Sun.COM emailed in 2007 the following answer.

The test result makes sense. The CDS archive provides startup time benefits even if there's only one JVM process. There is no incremental startup benefit for additional JVM processes. This is due to the nature of the sharing implementation. The first JVM doesn't do any additional incremental work on behalf of subsequent VM processes. Each process starts from the same point with respect to the shared archive. All the work before that was done by the initial archive creation (-Xshare:dump) process. In this way, all JVM processes benefit from the startup time savings, no matter whether it's the first or hundred-and-first process.

Steve's explanation makes sense based on the assumption that the shared archive file classes.jsa is not loaded at all when a JVM process is started with the option "-Xshare:on". Therefor all JVM processes are having the same amount of saving on the start up time.

After installing JDK 6u2, I tested the "-Xshare" again on a Windows XP system with StartupTimeTest.pl modified to run JDK 1.6.0 java command. Here are the results:

perl StartupTimeTest.pl jdk160_off
Hello world!
Hello world!
...
Command: \progra~1\java\jdk1.6.0_02\bin\java -cp . -Xshare:off Hello
Total time: 16 seconds
Average time: 0.16 seconds

perl StartupTimeTest.pl jdk160_on
Hello world!
Hello world!
...
Command: \progra~1\java\jdk1.6.0_02\bin\java -cp . -Xshare:on Hello
Total time: 11 seconds
Average time: 0.11 seconds

The saving on start up time provided by CDS on JDK 1.6.0 is quite significant.

Last update: 2007.

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)

 What Is Class Data Sharing?

 Regenerating Shared Archive

 Startup Time Saving with Restoring Shared Archive

Startup Time Saving with Multiple JVM Processes

 Footprint Saving with Restoring Shared Archive

 Viewing Shared Memory of JVM Processes

 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

 References

 PDF Printing Version