JVM Tutorials - Herong's Tutorial Examples - Version 4.23, by Dr. Herong Yang
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
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
JRockit JVM 28.2.7 by Oracle Corporation
Memory Management and Garbage Collectors
JVM Stack, Frame and Stack Overflow
Thread Testing Program and Result
CPU Impact of Multi-Thread Applications
I/O Impact of Multi-Thread Applications
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