2

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:

  • System boot time: outside the scope of this question. The only impact is Java is started quite early, so some other background processes might be stealing Computing Power; maybe some priority scaling could help, at the expense of some other process.
  • Java VM startup: this is the main focus of this question.
  • Application Startup time: this should be computed in the optimization, but application optimization itself (e.g.: delayed loading of "unused" classes") is not part of this question. It should be kept in mind, however, because any solution shortening VM launch time, but lengthening Application startup time won't help much.
ZioByte
  • 2,690
  • 1
  • 32
  • 68

1 Answers1

3

1. AOT Compilation ($$$)

Depending how deep is your pocket, you could try Excelsior JET compiler which supports ARM architecture. Compile the lot and have heavily streamlined and optimised executable for the platform, heavily mitigating JVM's startup time. 180 day free trial available, so enough to evaluate the option.

2. Compact Profiles (free)

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.

3. Compile your own JVM (free, complex)

Extensive knowledge in this presentation (also discussion around Compact Profiles)

4. Java 9 modules (free but alpha stage)

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.

diginoise
  • 7,352
  • 2
  • 31
  • 39
  • Unfortunately I have *not* the freedom to change the VM (and/or to use AOT). I will investigate your Option2, which is the only one I can pursue, at the moment. I will also try to use the Option1 "evaluation" and I will try to sell the upgrade to my bosses, if gains are substantial (I have scarce chances there, though, and it isn't a cost issue). If any of the options turns out to be useful I'll accept your answer. – ZioByte May 11 '18 at 11:36
  • @ZioByte "If any of the options turns out to be useful I'll accept your answer". Just accept it... It's a great answer with a lot of information. – Michael May 16 '18 at 09:10