Take-Two Interactive Software Privacy Policy (take2games.com)
1 points by swat535 16m ago 0 comments
Elon Musk says he is launching new political party (bbc.com)
2 points by miohtama 49m ago 0 comments
Let's Take a Look at JEP 483: Ahead-of-Time Class Loading and Linking
50 ingve 29 3/28/2025, 11:11:55 AM morling.dev ↗
With PGO you do a lot of deliberate work to profile your application under different conditions and feed that information back to the compiler to make better branch/inlining decisions. With a AOT cache, you do nothing up front, and the JVM should just dump a big cache to disk every time it exits just in case it gets stared again on the same host. In this case, training runs would just be a” run you did to create the cache". With that said, the big technical challenge right ow is that building the AOT cache is expensive hence performance impacting and cannot really be done alongside a live application - but that’s where I think the focus should be, making filling the aot cache something less intensive and automatic.
Another aspect this strategy would help with is “what to do with these big AOT cache files”, if the AOT cache really starts caching every compiled method, it will become essentially another so file possibly of a size greater than the original JAR it started off with. Keeping this is in a docker image will double the size of the image slowing down deployments. Alternatively, with the aot cache concept, you just need to ensure there is some form of persistent disk cache across your hosts. The same logic also significantly helps CLIs, where I dont’ want to ship a 100MB CLI + Jlink bundle and have to add another 50MB of aot cache in it - what I do want is every time the client uses my CLI the JVM keeps improving the AOT cache.
I’m not asking if the tooling currently exists, I’m curious if there’s something inherent in .class files that would prevent static linking.
It's not so much a problem with the .class files, instead it's a problem with reflection.
I can write `var foo = Class.forName("foo.bar.Baz")` which will cause the current class loader to look up and initialize the `foo.bar.Baz` class if it's available. I can then reflectively initialize an instance of that class by calling `foo.newInstance()`
Java has a ton of really neat meta-programming capabilities (and those will increase with the new ClassFile api). Unfortunately, those make static compilation and dead code elimination particularly hard. Tools that allow for static compilation (like graal) basically push the dev to declare upfront which classes will be accessed via reflection.
It's hard, and some might argue impossible, to statically analyze reachability in a dynamic language like java that allows for runtime class loading and redefinition. As it turns out, Java is much closer to javascript than C++ in terms of dynamic runtime behavior.
AOT compilation certainly doesn't give you the best outcome for all of these concerns (regardless of the language).
Does this mean this is mostly focused on containerised environments? I assume it means you couldn't upgrade the JVM on a server and know that this will keep working?
"App Images" are what these are called in Android afaik. ART (the Android Run Time) has been capable of "AoT Class Loading & Linking" since 2016/7 (and ~pauseless GC since 2019). Seems like the desktop/server grade JVMs have a lot of ground to cover.
You should expect a runtime that is used more on the server side to be "behind" when it comes to concerns that are more prevalent on the client and vice-versa, and that's exactly what you see.
True, but the Client x Server concerns seem to be overlapping now, across the board. For instance, tech built for ChromeOS (a desktop class OS) is also used by GCP ("Container-optimized OS") and AWS ("Firecracker").
While ART has had tiered compilation (C1/C2 in the OpenJDK world) for quite a while. I also mentioned ART has long had Copying Collector (almost pauseless GC), which could help Server-grade apps just the same.
All that said, for ART, things are relatively "simpler" as it has to only target Linux+Fuschia on ARM32/64, x86/amd64, RISC-V ISAs.
An interesting side note about Dalvik/ART (Zygote) is that it uses the old Server-side technique of forking (but without exec; like httpd's "fork mode") to share pages and resources with its children (ie, with all app processes on Android).
Sure, which is why you're seeing this work.
> While ART has had tiered compilation (C1/C2 in the OpenJDK world) for quite a while. I also mentioned ART has long had Copying Collector (almost pauseless GC), which could help Server-grade apps just the same.
I hope you're not suggesting that ART has a similar quality of compiler optimisations and GC as the JDK. But if you are, you're welcome to try and run significant server workloads on ART and see how they compare to JDK 24.
BTW, the last (Go-style) non-copying collector was deprecated in the JDK in 2017 and completely removed in 2020: https://openjdk.org/jeps/363. The reason why the low-latency GCs (what you call "almost pauseless") aren't the default in the JDK is that minimising latency is not (yet?) the top requirement for server apps. Some value throughput more.
At the end of the day, we care about the latency for some particular thread(s), and truly minimising that at this level requires a realtime kernel (that comes with significant performance disadvantages).
In my defense, I called it "~pauseless" (as in, roughly pauseless).
https://www.ptc.com/en/products/developer-tools/perc
https://www.aicas.com/products-services/jamaicavm/
https://eclipse.dev/openj9/docs/aot/
https://www.ibm.com/docs/en/sdk-java-technology/8?topic=refe...
Now gone, https://en.wikipedia.org/wiki/Excelsior_JET
What you are getting now is commercial work being offered as free beer, also why Excelsior JET is no longer relevant as company.
> On the contrary, lots of this work was already present in commercial products
I should have been clearer that I meant other OSS JVMs have catching up to do.
> long before Android
True. The evolution of Dalvik/ART remind me of HP Dynamo: https://archive.arstechnica.com/reviews/1q00/dynamo/dynamo-2...
> What you are getting now is commercial work being offered as free beer
... AOSP is free as in beer.
True, however it isn't Java proper, and apparently Google has started to rewrite subsystems in Kotlin as well, when initially they said the OS layers would still be Java (language).
Apparently the updates to Java 11 and 17 LTS subsets in ART, were motivated to keep up with Maven Central more than anything else.