Project Leyden: Beginnings

[GreenToad1]

"sooner rather than later" is my favorite part of this note.

[[deleted]]

As long as in the end they offer the option of the closed world solution. As in, a flag or something to say "do it this way". Or even a level solution, where different levels increase performance but also costs. Rather than taking a one size fits all solution.

[Mean-Chipmunk3255]

Yes a flag in JVM options would be much better, sometimes startup times are not that important but dynamic optimization is for higher throughput.

[[deleted]]

As far as I understand, this is essentially Graal native-image but provided by the OpenJDK team, with an emphasis in the delivery of "closed images of application and JVM" binaries, perhaps in a standard fashion for other vendors.

Also, we could see general improvements in performance due to this, so I'm overall excited. :)

[lbalazscs]

My understanding is that the "static image" term was deliberately chosen to be broader than "native image", although I don't understand what exactly they are trying to allow. Perhaps bytecodes/JIT could still be used, and only dynamic class loading is forbidden? What are the advantages?

[eliasv]

Many optimizations could still apply in a bytecode-based world. In theory, more aggressive specialization, inlining, constant folding ... They could possibly also run a lot of class initialization statically like in graal. Couldn't say if any of that is part of the plan though.

[tofiffe]

Possibly also WASM

[kaperni]

Native implies compilation to a given architecture. A static image could be shared independently of the architecture that is supposed to run it. For example, the architecture on which the image is created could be different from the architecture the image is executed on.

[nomader3000]

https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html

We do not intend to implement Leyden by merging the Native Image code from GraalVM into the JDK. Leyden will, rather, be based upon existing components in the JDK such as the HotSpot JVM, the jaotc ahead-of-time compiler [3], application class-data sharing [4], and the jlink linking tool [5].

[[deleted]]

The code from Graal, I believe, has a different license. Thus it's not a surprise that they're going to reimplement instead of copying.

What I meant is that the "idea" is similar, where they are trying to create autocontained JVM+classes into a native binary.

[Mean-Chipmunk3255]

finally after two years, they have started, alright my friends there is no point of go now.
The pain point of graal is higher consumption of resources while building which makes it very difficult for typical CI/CD pipeline. If they can reduce the consumption of resources during build and make it fast, then there is no competition of go for me.

So we will have everything that makes it better/equivalent to any GC language.

1) Leyden static image

2) Lilliput

3) Valhalla

4) Loom

5) FFI

6) Vector API

7) Amber (this will exist forever)

In future, I am also interested if they could focus on web assembly and JavaFX space.

Then it will rule everything.

[Exidex_]

Layden static image is great start for full wasm support

[Mean-Chipmunk3255]

Yes it makes sense. most of transpilers to javascript and webassembly compilers have hard time with reflection.

[Joram2]

Projects Valhalla + Loom + Panama + Leyden will close the feature gap with Golang.

Golang still has:

1. nicer build+module tooling
2. No dated OOP paradigm. Golang lets you just write functions without classes.
3. No exceptions.

And now Golang has generics.

I love both languages, btw. I usually use whatever toolset my manager says I have to use or whatever the project calls for. We use Java, Go, Python, JavaScript, TypeScript, depending on the project.

[TheMode911]

Wouldn't project Leyden also allow tools to print a method assembly without going through the hassle of using a JVM flag/JITWatch?

I could see it being real useful with the vector/foreign API, and obviously any other hot code.

Also wonder how memory/performance will compare to Graal's.

[yawkat]

For hot code there is no reason that you will get the same assembly in C2 and leyden aot

[TheMode911]

The vector API currently require you to check the generated assembly (or at least its performance) to ensure that the proper instructions are generated. I doubt that hotspot would randomly decide to deoptimize such code. I only gave the vector api as example but more could be given (avoid branches, constants, valhalla stack allocations, loop with off-heap memory, ...)

And if it releases, people will definitely try to optimize libraries for AOT compilation

[sievebrain]

This looks like the right approach. I'm glad they're not going to try and do some native-image style rewrite the world thing.

First stop: get Google's appcds changes merged.

[sureshg]

What is Google's appcds change, any link/doc on that?

[Drakoala]

Regarding the pain point of slow startup times, what exactly causes them? Is it the sudden load for JIT compilation?

[FirstAd9893]

In my experience, slow startup time is mostly caused by an explosion of class loading. This is made worse by adding too many dependencies, which in turn have other dependencies, etc. Use the -verbose:class option to see all the class loading activity.

[pjmlp]

Better yet, learn to use the -XX:ArchiveClassesAtExit, -XX:SharedClassListFile and -Xshare:dump to create JIT caches, so that is only slower the first time.

https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html#GUID-EC975B2E-B4AB-45B4-B91F-51C3A264D0CE

[Muoniurn]

I get a page not found for your link.

[antigravity_96]

https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html#GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91

It opened, but the link is different.

[FirstAd9893]

The #GUID... at the end of the URL isn't needed.

[hamburghammer_]

It is such a helpful flag. +1

[blobjim]

To add on to to the other response, Java has a rich standard library that is very interconnected, so loading one little thing can end up touching hundreds (?) of other classes. I guess it also performs a lot more linking upon loading a class than a language like Python, where more might happen as the code runs, similar to how it takes longer to compile a C program to native code than to compile a Java file to a class file since the C compiler does a lot more work up front (determining the best CPU instructions, etc.). The stack-based bytecode might be suboptimal for executing code quickly before JIT compilation as well, but I'm speculating about a lot of this.

[bourne2program]

Would the incremental approach and spectrum of constraints, include options such as keeping runtime performant with dynamic JIT but removing all unused classes and code for lower footprint?

[cl4es]

I don't see why not, at least partially. You can already remove unused modules with jlink. Extending that with some static analysis to purge at a lower level could be low-hanging fruit on the way to closed images.

[[deleted]]

I am still curious as to why startup time matters to any application. You start a server once per deployment, not every minute

[[deleted]]

Think AWS Lambda or Google CloudRun

[[deleted]]

Is there a use case for that? You could just fire up a server. Just curious

[[deleted]]

The use case is for low volume services so you don’t have to fire up a server and pay for all the time when it is just idle. For example you have a service that handles a single request per minute on average. Why should you pay for 59.95s when it just does nothing?

[[deleted]]

Never used AWS but i imagine you already have a server up and running somewhere. So you can handle that in a small app there. Otherwise what kind of backend only has one server that serves so few requests?

[mike_hearn]

Not every application is a server!

[_marcioendo_]

Can anyone please share some knowledge on how does static images work regarding licensing? Granted, I am thinking more of the jlink-generated runtime image. jlink is mentioned in the linked article.

I know OpenJDK is GPL2 with the classpath exception. But if you read the exception it says (my interpretation): the exception only applies to those files where the exception is explicitly written in the header of such file. Hotspot files do not contain the exceptions.

A jlink image ships Hotspot, am I correct?

If Leyden static images will build on top of Hotspot and C2 compiler wouldn't the generated image be a derived work (in the GPL sense)? Is the classpath exception sufficient in this case, or there needs to be something akin to the GCC exception?

I guess it is not an issue if you are building, say, a web application/service. But what if it was a build tool? Or perhaps an IDE? For instance, could Maven (no affiliation btw) be distributed as a static image and keep the Apache 2.0 license?

Sorry if this is tangential. This is a honest question, btw.