7 ms·

One thing that is hurting Java today is memory usage. Conventional JVMs use a lot of memory relative to essentially everything else and this is drives up cloud

One thing that is hurting Java today is memory usage. Conventional JVMs use a lot of memory relative to essentially everything else and this is drives up cloud bills. There are alternative JVMs and other tools, some of which is embryonic at this point, but what the world wants and what Java really needs to continue thriving is efficient memory use by the bog standard JVMs that work with everything.

klysm 6y ago
Yeah it’s especially painful once you near 32GiB
apta 6y ago
With project Valhalla (value types), as well as the GC improvements in recent JDK releases (e.g. they are much more aggressive in releasing unused heap back to the OS), this should be a much smaller issue going forward. On another note, I'm not aware of other freely available GCs in other languages that are able to easily scale to multi-GB/TB scale memory usage. A while ago, I benchmarked an open source key/value golang project and it performed miserably when it reached GB level memory usage.
- vips7L 6y ago
  > e.g. they are much more aggressive in releasing unused heap back to the OS By aggressive you mean they actual do that now right? As far as I know before ZGC no gc did that and they're still back porting that feature to G1 right? Edit: I'm actually quite pleased with ZGC I have the eclipse language server use it and my editors memory usage on average is so much lower.
  - apta 6y ago
    I believe it has been backported to JDK14 (and JDK15 was released this past week). Also Shenandoah should be production ready in JDK15, so you might want to give it a shot.
  - sideeffffect 6y ago
    Shenandoah is coming to OpenJDK 11. See my other comment for more details: https://news.ycombinator.com/item?id=24571054 https://news.ycombinator.com/item?id=24571054
jacques_chester 6y ago
> One thing that is hurting Java today is memory usage. Agreed. GraalVM is showing enormous promise in this area, alongside efforts like Project Valhalla. I think the emergence first of microservice and then of FaaSes has lit a fire underneath OpenJDK folks and others in the ecosystem.
throwaway189262 6y ago
That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the world pauses get longer with more garbage. Javas new collectors are near constant time, even with terabytes of garbage, so it's much more efficient to wait until the heap builds up and collect much less frequently. Ironically, Java appears to use tons of ram because it has better garbage collectors. When you configure Java GC to collect frequently, it turns out Java uses 2-3X less ram than JS, and far less than Python, Ruby, etc. It does use more than Go, about 2X. But the point is it uses a lot less ram than most other popular languages for web dev. Unfortunately the "Java uses too much ram" is used in defence of using things like JS and interpreted languages, when in actually it uses much less if you configure it to.
- philipkglass 6y ago
  I'll shamefully admit that I have been running and writing JVM based services for years and I didn't know this. I thought that the fixed memory overhead for a simple JVM service was simply higher than with CPython as a fact of life. There are times when I'd happily trade more frequent GC pauses for a smaller per-process memory footprint. How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions?
  - spullara 6y ago
    Depends on your application and how much memory you actually need. I would also use ZGC as it returns unused memory to the system and low ms maximum pause times for terabytes of heap.
  - throwaway189262 6y ago
    > 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
The_rationalist 6y ago
The situation is improving https://openjdk.java.net/jeps/387 https://openjdk.java.net/jeps/387

klysm 6y ago

Yeah it’s especially painful once you near 32GiB

apta 6y ago

With project Valhalla (value types), as well as the GC improvements in recent JDK releases (e.g. they are much more aggressive in releasing unused heap back to the OS), this should be a much smaller issue going forward. On another note, I'm not aware of other freely available GCs in other languages that are able to easily scale to multi-GB/TB scale memory usage. A while ago, I benchmarked an open source key/value golang project and it performed miserably when it reached GB level memory usage.

vips7L 6y ago
> e.g. they are much more aggressive in releasing unused heap back to the OS By aggressive you mean they actual do that now right? As far as I know before ZGC no gc did that and they're still back porting that feature to G1 right? Edit: I'm actually quite pleased with ZGC I have the eclipse language server use it and my editors memory usage on average is so much lower.
- apta 6y ago
  I believe it has been backported to JDK14 (and JDK15 was released this past week). Also Shenandoah should be production ready in JDK15, so you might want to give it a shot.
- sideeffffect 6y ago
  Shenandoah is coming to OpenJDK 11. See my other comment for more details: https://news.ycombinator.com/item?id=24571054 https://news.ycombinator.com/item?id=24571054

jacques_chester 6y ago

> One thing that is hurting Java today is memory usage. Agreed. GraalVM is showing enormous promise in this area, alongside efforts like Project Valhalla. I think the emergence first of microservice and then of FaaSes has lit a fire underneath OpenJDK folks and others in the ecosystem.

throwaway189262 6y ago

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the world pauses get longer with more garbage. Javas new collectors are near constant time, even with terabytes of garbage, so it's much more efficient to wait until the heap builds up and collect much less frequently. Ironically, Java appears to use tons of ram because it has better garbage collectors. When you configure Java GC to collect frequently, it turns out Java uses 2-3X less ram than JS, and far less than Python, Ruby, etc. It does use more than Go, about 2X. But the point is it uses a lot less ram than most other popular languages for web dev. Unfortunately the "Java uses too much ram" is used in defence of using things like JS and interpreted languages, when in actually it uses much less if you configure it to.

philipkglass 6y ago
I'll shamefully admit that I have been running and writing JVM based services for years and I didn't know this. I thought that the fixed memory overhead for a simple JVM service was simply higher than with CPython as a fact of life. There are times when I'd happily trade more frequent GC pauses for a smaller per-process memory footprint. How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions?
- spullara 6y ago
  Depends on your application and how much memory you actually need. I would also use ZGC as it returns unused memory to the system and low ms maximum pause times for terabytes of heap.
- throwaway189262 6y ago
  > 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

The_rationalist 6y ago

The situation is improving https://openjdk.java.net/jeps/387 https://openjdk.java.net/jeps/387