3 ms·

> How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions? That's tough to figure out. In new versions of Java, I think 14+, if

> How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions? That's tough to figure out. In new versions of Java, I think 14+, if you use ZGC collector it will return unused memory to the OS. Memory options vary depending on collector, but new versions of ZGC support "soft max" heap size and uncommit. Together it might be close to what you're looking for https://malloc.se/blog/zgc-softmaxheapsize https://malloc.se/blog/zgc-softmaxheapsize I should mention the GC situation was worse until the last few years. Until ZGC and Shenandoah came around, Java still didn't collect frequently but when it did there were long pauses. This is what V8 and Go's collectors were designed to avoid. They have more overhead from collecting frequently, but low pauses. With the new Java collectors you get the best of both worlds. You can set heap ratios and such for older collectors to decrease Java memory use with those, but IMO you're better off using ZGC and uncommit these days

philipkglass 6y ago
Thanks for the advice. I'm stuck on 11 until the next LTS release but I'll definitely be trying ZGC next year. (ZGC is in 11 but still marked experimental, and I'm conservative about making changes.)
- throwaway189262 6y ago
  That's probably a good decision. When ZGC was first released it didn't support class unloading, including in 11. This will lead to puzzling memory leaks in applications that generate a lot of code at runtime. Newer versions of ZGC support class unloading and have some other performance optimizations
- sideeffffect 6y ago
  Shenandoah might help you. See my other comment for more details: https://news.ycombinator.com/item?id=24571054 https://news.ycombinator.com/item?id=24571054
topspin 6y ago
> That's tough to figure out. Indeed. That fact obviates this option in most cases. You have to spend time tweaking obscure, unstable knobs (the X in Xmx means Oracle is free to alter its meaning at any time) and risk either a.) serious failures in production or b.) poor results because the conservative choices necessary to avoid 'a' achieved little improvement and you wasted your time. The real world for most enterprises is a vast heard of communicating components and toying with GC switches multiplied by N things is a nonstarter. So while you're technically correct that excessive memory use by conventional JVMs is "not always true," in practice you are wrong. That reality comes with a real cost that appears on a real bill every single month.
- throwaway189262 6y ago
  The cost of setting a few command line args? They're not really obscure or unstable, just different depending on the GC you use. Turning on ZGC and setting the right options is like 4 command line flags. It's very easy, the reason it's not frequently done is that nobody reads documentation and it's not the default. Go's approach of minimal knobs leads to unfixable problems in production. Java gives more options to tune GC for your use case
  - topspin 6y ago
    > Go's approach of minimal knobs leads to unfixable problems in production. I didn't bring up Go, but since you did the thing I see is that Go -- a much younger language -- is going places Java never has, or did so only haltingly. Caddy is a case in point. Here is Go taking on nginx, haproxy, Envoy, etc. The people that once imagined using Java for such things have retired or moved on to other battles. No one seriously ponders attempting 'systems' tasks with Java any longer; that whole space was ceded to more efficient languages. My opinion is that Java's poor efficiency -- a big part of which is its excessive memory consumption -- is the reason for this. That's my opinion. What I know for fact is that today, when people are making design decisions about new services and their deployment, Java is a problem; it is understood that anything implemented in Java is going to sort right to the top of the list of memory pigs in the cluster, and you can only afford so many of those.
  - 6y ago
hilbertseries 6y ago
> I should mention the GC situation was worse until the last few years. Until ZGC and Shenandoah came around, Java still didn't collect frequently but when it did there were long pauses. This feels like G1GC erasure. I'll also say we've tried out ZGC and while pause times were low, it had a huge CPU overhead and the performance of our application was notably worse and we went back to G1GC. We're still on Java 11, so maybe we'll see some magic when we eventually try the newer versions.
- sideeffffect 6y ago
  20th October, OpenJDK 11.0.9 will be released, with full-fledged Shenandoah GC. It has _very_ low pauses and has the `-XX:ShenandoahGCHeuristics=compact` option, which will promptly give unused memory back to the OS (thus keeping the whole memory profile low). Give it a try. https://wiki.openjdk.java.net/display/shenandoah/Main https://wiki.openjdk.java.net/display/shenandoah/Main https://www.slideshare.net/jelastic/choosing-right-garbage-collector-to-increase-efficiency-of-java-memory-usage https://www.slideshare.net/jelastic/choosing-right-garbage-c... https://twitter.com/shipilev/status/1308320432404168705 https://twitter.com/shipilev/status/1308320432404168705

philipkglass 6y ago

Thanks for the advice. I'm stuck on 11 until the next LTS release but I'll definitely be trying ZGC next year. (ZGC is in 11 but still marked experimental, and I'm conservative about making changes.)

throwaway189262 6y ago
That's probably a good decision. When ZGC was first released it didn't support class unloading, including in 11. This will lead to puzzling memory leaks in applications that generate a lot of code at runtime. Newer versions of ZGC support class unloading and have some other performance optimizations
sideeffffect 6y ago
Shenandoah might help you. See my other comment for more details: https://news.ycombinator.com/item?id=24571054 https://news.ycombinator.com/item?id=24571054

topspin 6y ago

> That's tough to figure out. Indeed. That fact obviates this option in most cases. You have to spend time tweaking obscure, unstable knobs (the X in Xmx means Oracle is free to alter its meaning at any time) and risk either a.) serious failures in production or b.) poor results because the conservative choices necessary to avoid 'a' achieved little improvement and you wasted your time. The real world for most enterprises is a vast heard of communicating components and toying with GC switches multiplied by N things is a nonstarter. So while you're technically correct that excessive memory use by conventional JVMs is "not always true," in practice you are wrong. That reality comes with a real cost that appears on a real bill every single month.

throwaway189262 6y ago
The cost of setting a few command line args? They're not really obscure or unstable, just different depending on the GC you use. Turning on ZGC and setting the right options is like 4 command line flags. It's very easy, the reason it's not frequently done is that nobody reads documentation and it's not the default. Go's approach of minimal knobs leads to unfixable problems in production. Java gives more options to tune GC for your use case
- topspin 6y ago
  > Go's approach of minimal knobs leads to unfixable problems in production. I didn't bring up Go, but since you did the thing I see is that Go -- a much younger language -- is going places Java never has, or did so only haltingly. Caddy is a case in point. Here is Go taking on nginx, haproxy, Envoy, etc. The people that once imagined using Java for such things have retired or moved on to other battles. No one seriously ponders attempting 'systems' tasks with Java any longer; that whole space was ceded to more efficient languages. My opinion is that Java's poor efficiency -- a big part of which is its excessive memory consumption -- is the reason for this. That's my opinion. What I know for fact is that today, when people are making design decisions about new services and their deployment, Java is a problem; it is understood that anything implemented in Java is going to sort right to the top of the list of memory pigs in the cluster, and you can only afford so many of those.
- 6y ago

hilbertseries 6y ago

> I should mention the GC situation was worse until the last few years. Until ZGC and Shenandoah came around, Java still didn't collect frequently but when it did there were long pauses. This feels like G1GC erasure. I'll also say we've tried out ZGC and while pause times were low, it had a huge CPU overhead and the performance of our application was notably worse and we went back to G1GC. We're still on Java 11, so maybe we'll see some magic when we eventually try the newer versions.

sideeffffect 6y ago
20th October, OpenJDK 11.0.9 will be released, with full-fledged Shenandoah GC. It has _very_ low pauses and has the `-XX:ShenandoahGCHeuristics=compact` option, which will promptly give unused memory back to the OS (thus keeping the whole memory profile low). Give it a try. https://wiki.openjdk.java.net/display/shenandoah/Main https://wiki.openjdk.java.net/display/shenandoah/Main https://www.slideshare.net/jelastic/choosing-right-garbage-collector-to-increase-efficiency-of-java-memory-usage https://www.slideshare.net/jelastic/choosing-right-garbage-c... https://twitter.com/shipilev/status/1308320432404168705 https://twitter.com/shipilev/status/1308320432404168705