I need to try to improve startup time of a relatively large headless java application tweaking VM/launcher parameters (a separate effort is underway to achieve the same goal tweaking the actual code).
The VM of choice is standard OpenJDK Java-8.
openjdk version "1.8.0_102-internal"
OpenJDK Runtime Environment (build 1.8.0_102-internal-b14, profile compact3)
OpenJDK VM (build 25.102-b14, interpreted mode)
Host computer is an embedded ARM7 (32 bit) running Linux.
model name : ARMv7 Processor rev 5 (v7l)
BogoMIPS : 38.40
Goal, as said, is to improve startup time; runtime performance is acceptable.
Can someone suggest tweaks to the VM itself to significantly improve lead time.
Note: I'm aware of possible benefits of "-client" option and I will experiment with it ASAP; are there possible drawbacks? Any other?
Clarification:
The "interesting number" is the time needed from target power-up to when application is ready to accept commands.
This is composed by three parts:
Java SE 8 Embedded has Compact Profiles. Your JVM startup log suggests that your application uses compact3 (the biggest of the 3).
Each profile is essentially a set of Java APIs (and therefore related classes) and compact3 contains all APIs from compact2 with additions, while compact2 contains all APIs from compact1 with additions.
Running javac -profile 2
(ore even -profile 1
) will show you errors when you are using APIs from outside of the specified profile. jdeps -P
will show you profile per API consumed. Perhaps you could avoid using API from higher profiles allowing your application to be compiled to a lower profile API. This would result in less classes loaded by the bootstrap/system classloader, and therefore quicker JVM startup. See here for more info.
Extensive knowledge in this presentation (also discussion around Compact Profiles)
I am not sure whether there exists successful port of JVM 9 to ARM yet. Azul Systems' Zulu is only up to Java 8. OpenJ9 is Eclipse's effort however ARM port of it seems a bit experimental still. Have a look, perhaps you could get some traction for your application.
It will require creating modules within your codebase and building up JRE only with modules used by your application.