13

I've heard that

  1. JVM becomes faster (in some ways) with each major release
  2. modularity of 9 will bring faster startup time.

In an attempt to speed up a Maven build, I've downloaded jdk9-ea and find out that it takes even longer with it. Moreover, it feels like there is a longer delay before Maven starts.

I've tried to roughly measure JVM startup time using following code

public class Sampler { public static void main(String[] args) throws IOException, InterruptedException { long t = System.currentTimeMillis(); if (args.length == 0 || args[0].startsWith("-")) { sample(30, args); } else { long t0 = Long.parseLong(args[0]); System.out.println(t - t0); } } static void sample(int n, String[] options) throws IOException, InterruptedException { File samples = new File("samples.txt"); for (int i = 0; i < n; i++) { String javaPath = String.join( System.getProperty("file.separator"), System.getProperty("java.home"), "bin", "java"); List<String> command = new ArrayList<String>(); command.add(javaPath); command.addAll(Arrays.asList(options)); command.add("Sampler"); command.add(Long.toString(System.currentTimeMillis())); ProcessBuilder processBuilder = new ProcessBuilder(command) .inheritIO() .redirectOutput(ProcessBuilder.Redirect.appendTo(samples)); Process process = processBuilder.start(); process.waitFor(); } prettyPrint(samples); samples.delete(); } ... }

And it takes twice as long to start with Java 9

 >java -version java version "1.8.0_74" Java(TM) SE Runtime Environment (build 1.8.0_74-b02) Java HotSpot(TM) Client VM (build 25.74-b02, mixed mode, sharing) >javac Sampler.java && java Sampler n=30 units=milisec min=124 max=205 mean=143 median=132 >java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+111) Java HotSpot(TM) Client VM (build 9-ea+111, mixed mode) >javac Sampler.java && java Sampler n=30 units=milisec min=279 max=387 mean=301 median=294 >javac Sampler.java && java Sampler -XX:+UseParallelGC n=30 units=milisec min=279 max=382 mean=297 median=292 >java -version java version "1.8.0_76-ea" Java(TM) SE Runtime Environment (build 1.8.0_76-ea-b04) Java HotSpot(TM) Client VM (build 25.76-b04, mixed mode, sharing) >javac Sampler.java && java Sampler n=30 units=milisec min=123 max=227 mean=159 median=141 >java Sampler -XX:+UseG1GC n=99 units=milisec min=188 max=340 mean=213 median=199

Note: Originally I've used Server VMs (x64), same 2x gap, Java9 startup time was around 0.6sec.

After java -Xshare:dump

 >java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+111) Java HotSpot(TM) Client VM (build 9-ea+111, mixed mode, sharing) >javac Sampler.java && java Sampler n=50 units=milisec min=228 max=422 mean=269 median=269 >javac Sampler.java && java Sampler -Xshare:on <error messages> n=44 units=milisec min=227 max=392 mean=247 median=238 >javac Sampler.java && java Sampler -Xshare:off n=50 units=milisec min=280 max=513 mean=315 median=288 >javac Sampler.java && java Sampler -Xshare:auto n=50 units=milisec min=228 max=361 mean=283 median=285

With Java 8 ea

 >java -Xshare:off Sampler n=99 units=milisec min=124 max=264 mean=150 median=136

Error message: 

 An error has occurred while processing the shared archive file. Unable to map ReadOnly shared space at required address. Error occurred during initialization of VM Unable to use shared archive.

44 successful starts out of 50 is the highest number I could get. Lowest was - 13.

Improve this question
6
  • 4
    are you actually focused on VM startup time, your maven build time or JVM speed? You seem to use all these terms like they are the same, but they are not. Commented Feb 3, 2016 at 14:48
  • 2
    I'm focused on startup time as title implies. Other 'terms' not meant to be used as equal, but certainly related to each other. Maven being an example of a well known program where startup time has significant share in overall execution time. In my understanding startup is an important characteristic of VM performance (speed) and mvn build is VM performance in action. Not sure if this is more clear than what I sad originally but here. Commented Feb 3, 2016 at 18:22
  • 2
    Maven is certainly not yet written in java 9 in mind. JVM speed usually refers to execution speed - depending on server/client modes you can actually choose if you want to emphasize startup times or JVM speed, and which kind of memory characteristics. Commented Feb 3, 2016 at 19:06
  • Jigsaw was just merged into JDK9 on build 111. I suggest you download that build and try measuring the startup times again. Commented Mar 29, 2016 at 10:10
  • It could be just debugging code that is making it slower. I think it would make sense to find an ea version of Java 8 and compare it to that. Then you could at least count for non-production code release issues. Commented Mar 29, 2016 at 20:54

2 Answers 2

Reset to default
9

Yes, there definitely are some startup regressions in current EA builds - some causes are known and actively worked on - others are more of a "Death by a thousand cuts" ordeal: small, insignificant inefficiencies accumulated over the course of development of JDK 9 as features are implemented and integrated, which then has to be fine-tuned and optimized before actual release.

Edit: In subsequent JDK releases we eliminated most startup regressions introduced with JDK 9. One notable exception is startup regressions caused by JEP 280 where innocuous string concatenations in the JDK library may cause small but noticeable overheads in some applications.

Improve this answer
Sign up to request clarification or add additional context in comments.

4 Comments

Would you mind adding the list of known causes to your answer?
In linked guide said that class data sharing is supported only with the serial garbage collector. Could you comment on that too?
Jigsaw itselfs currently adds some setup work during startup, but enables startup optimizations elsewhere, e.g., JDK-8152641. 9+108 caused a regression related to Multi-Release JARs which should make it into 9+113, see JDK-8152733.
CDS was made to nominally work on all collectors and on both server and client VMs with the permgen removal (so JDK 8), but IIRC it's only enabled by default when running with the serial collector on client VM. Whether or not it's supported on anything but the serial collector I honestly don't know. I'll ask around, but I think the technotes needs to be updated and clarified.
3

It's likely that G1 garbage collector, which is default on Java-9, causes significant startup delay. Try -XX:+UseParallelGC on Java-9 or -XX:+UseG1GC on Java-8 to check with the same garbage collector.

Improve this answer

2 Comments

How can you explain that ParallelGC does not make Java 9 perform any better?
Startup performance of G1 has been greatly improved in Java 9 compared to 8 (where it could often double startup times). It still has a measurable cost compared to -XX:+UseParallelGC, but it's either noise or around 10ms on most of the hardware we measure on.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.