Comment by imtringued | Hacker News Reader

Comment by imtringued | Hacker News Reader

I'd like to see a JVM with a garbage collector that isn't designed to always consume the maximum amount of memory before it starts collecting. If you configure the JVM to have at most 400MB and it's current heap size is 120MB and you allocate 0.5MB every second or simply allocate 400MB of temporary objects that could be collected right away, it will allocate more GC heap until it hits the maximum 400MB and only then it decides to start a collection cycle. This makes the JVM useless for anything that isn't a web server that uses the entire RAM anyway.

Although Shenandoah looks promising but it's pretty telling that even in 2019 the JVM only has a single good garbage collector and it's still experimental. 23 years of history my ass. Other than the awful JEE ecosystem, the JVM is probably the worst part about the Java ecosystem. You can't fix it with a language that runs on top of it. It's slow (mostly startup performance), the GC is awful and it gobbles up a huge amount of memory. Obviously my company doesn't care because 8GB of RAM for a webserver costs them almost nothing.

It wouldn't surprise me if a WebASM implementation will take over one day, because the JVM is such a failure.

The JVM has state of the art GCs, name another platform that comes close in terms of offering the ability to tune it for throughput or latency as the JVM does, or that comes close in performance (.NET probably is the only contender).

If you don't want memory usage to go up to 400MB, then you can set the maximum memory the JVM can use to less than 400MB. It only makes sense from an efficiency and throughput standpoint to use as much memory available for performance.

JVMs regularly run on GBs or even TBs of heap space in production.

Both Shenandoah and ZGC target lower pause times (at the expense of throughput, naturally). There are commercial offerings like offerings from Azul that target low pause times as well.

> the JVM is probably the worst part about the Java ecosystem

On the contrary, the amount of optimizations that the JVM performs, as well as the monitoring, management, hotswapping, etc capabilities are second to none.

> It's slow

The fact that the JVM tops several charts here says otherwise: https://www.techempower.com/benchmarks/#section=data-r17&hw=...

> (mostly startup performance)

This is already being resolved through GraalVM. See for example https://quarkus.io/

> because the JVM is such a failure.

It only runs the backends of companies like Amazon, Google, FB, EA, LinkedIn, Ebay, Apple, Netflix, and countless others. Not to mention it's being used in high performance spaces like HFT.

I don't think any of your description about how the JVM GC works is accurate. The default GC is generational so it generally does lots of garbage collection before it takes up the reaches the heap limit. I assume what you really want is for the Java heap to return memory to the OS. The default JVM GC isn't configured to do that but you can easily configure the JVM to do that.

> JVM is such a failure

I'm genuinely confused why you would consider that to be the case. Especially since your preferred alternative (WebASM) is just about as bad or worse by your stated measures (start up time, GC).

I'm not sure what your real world experience with Java is, but GC is actually quite good and in server side Java I had no issues for years. G1 evolves and I had no issues with it. In Java 12 there is ZGC that have similar goals as Shenandoah, too. It is not like Shenandoah is something that is intended to be mainstream in Java. While G1 is optimized for throughput, Shenandoah is sacrificing performance for very short stop-the-world phase. It really depends on your requirement which one is better. There were multiple GCs before and alternative vendors have their own, for sure. What is your current pick and why is it so much better?

JVM is really good tech, it allows ecosystems like Scala, Kotlin, Clojure etc to exist. Since Java 8 there is class data sharing that may reduce your startup time and memory requirements a lot, especialy if you run multiple instances with same classes on same server.

Java ahead of time compilation was experimental since Java 9 and GraalVM should also help a lot if startup time is critical.

And, of course, even G1 does not fill all memory before it starts collecting. Even generational GCs before G1 divide memory into smaller areas and try to collect garbage quickly to get rid of short lived objects, so we're speaking about Java 6 timeframe. Example from my real world server - most of objects are collected at young generation, so gc costs are minimal, very few objects get promoted to old generation and full GC runs are very sporadic (and they are sub 1sec).

Reply on news.ycombinator.com