Hacker News Reader

Comment by layer8 | Hacker News Reader

The startup cost is dominated by class loading, which Jacobin will have to do more or less the same as OpenJDK [*]. GraalVM of course profits from AOT compilation.

[*] until the latter will implement condensers: https://openjdk.org/projects/leyden/notes/03-toward-condense...

View on HN

Didn't they introduce some new format with Java 9 and jlink to store modules more efficiently? Why hasn't that fixed class loading performance?

The issue isn’t the format. Class loading includes bytecode verification (verifying the type soundness of whatever code the class files contain), and then executing the initialization code defined by each class (static code blocks etc.).

The optimizations in JDK 9 are for reducing the file size of the JDK (in terms of number of classes) when distributed with a standalone application, but that by itself doesn’t significantly affect startup time I believe, because classes are lazy-loaded only as required in any case.

The jimage format does optimize startup a bit because it builds a perfect hashtable to go from class name to classfile bytes. On the classical classpath that requires an O(N) scan of the JARs in the app.

Does a JVM really need to re-verify the standard library it ships with?

It’s actually the default to not do that (-Xverify:remote). So I was probably wrong about bytecode verification being a relevant part of startup time, unless you count the application itself.

The modules system is for better encapsulation and the ability to produce a JVM without features you don't need.

Faster start up time is in the works with projects like coordinated restore at checkpoint which will let you start a JVM up in an already "warmed" state.

https://github.com/CRaC/docs

If I understand the README correctly, CRaC in an abstract API that delegates to an implementation (CRIU) which is Linux-specific, described in its README as "the never-ending story, because we have to always keep up with the Linux kernel".

So this wouldn't help if I'm deploying a GUI app for Windows, for example.

Correct, it might, someday, become part of Java SE. If that ever happens I would expect it working on every platform Java supports would be a prerequisite for that.

Right now it's primarily useful for reducing start up times in AWS Lambdas and auto-scaling workloads.

It improves it a bit, and AppCDS improves it a lot (~30% startup win), but neither feature is widely used as it changes deployment workflows.

Reply on news.ycombinator.com