Comment by AlotOfReading
3 hours ago
LLVM does speculative devirtualization as well these days, though it's not as aggressive as Hotspot. High-performance native code tries to avoid deep dynamic hierarchies anyway, so it's mitigated by cultural practices.
GCs are definitely a strong point for Java, but most high-performance code can be rewritten to avoid pummeling memory management. This used to be common for Java in financial applications, not sure if it still is.
C++ has evolved its own compacting GCs like oilpan [0] for applications where high performance is inherently tied to allocation. Oilpan runs into pointer issues and isn't remotely comparable to G1GC or ZGC, but I think the speed of V8 speaks for itself. Rust allows you to drop in non free-list based allocators and GCs (e.g. Bumpalo), but they're relatively immature.
That may be because the information on that page seems to be up to date to 2011-2. Java is now on version 26, BTW.
The last time I dove into JVM internals was around the same time. I figured that someone who's worked with it more recently might have better examples than what's easily searchable.
[0] https://chromium.googlesource.com/v8/v8/+/main/include/cppgc...
> LLVM does speculative devirtualization as well these days, though it's not as aggressive as Hotspot. High-performance native code tries to avoid deep dynamic hierarchies anyway, so it's mitigated by cultural practices.
Sure, AOT compilation also didn't stand still, and overall I'd say that Java and low level languages are closer today than they were 20 or even 10 years ago on all fronts: both have improved in areas where they were behind.
> This used to be common for Java in financial applications, not sure if it still is.
Given that low-latency collectors are only 3 years old, I'm sure some existing Java applications still do it, but new ones no longer need to (and it may turn out to be counterproductive with the new collectors)
> Rust allows you to drop in non free-list based allocators and GCs (e.g. Bumpalo), but they're relatively immature.
The problem isn't the immaturity but the integration with the standard library that requires significant code changes (e.g. you need to use different string and collection implementations). However, even where there is good integration - as in the case of Zig - arenas impose limitations (due to the care that needs to be given to lifetime) that make the program less flexible. But yes, when all the stars are aligned, arenas can beat moving collectors (that's about the only thing that can), but moving collectors aren't standing still and resting on their laurels, either.
> I figured that someone who's worked with it more recently might have better examples than what's easily searchable.
I don't know about a single unified resource, but you can find everything here: https://openjdk.org/jeps/0
JIT improvements are usually too low-level to merit a JEP, but all the major GC changes are there. For a taste of what's going on in the JIT these days, see this recent talk: https://youtu.be/J4O5h3xpIY8