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) 2003 by Dr. Herong Yang, herongyang.com
*/
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.
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:
