Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem with the JVM, compared to Go, is the GC; it requires a lot of reserved memory. Go programs use far less. And the SDK is bulky, which can be a problem for container images - although arguably it should be considered irrelevant, as you only download base images once, if done correctly.


You're not supposed to use the runtime directly these days. jlink allows you to strip unnecessary things (like documentation for the runtime itself), extract only those parts of the runtime you need (though your project must use modules to support that), and then aggressively compress it all getting a pretty small package that runs on an empty OS with no dependencies other than libc. It's still a bunch of files, so for good user experience you would have to ship it as a container (or something like .exe or appimage), but it's really close to Go in terms of size.

https://www.baeldung.com/jlink


It's a configurable property, and Java has a bunch of GCs to begin with.

Also, not using as much memory in these types of GCs is a direct hit to performance. And this actually shows splendidly on GC-heavy applications/benchmarks.


We were paying a million a month for a custom high performance GC for a little bit but we were able to get off that with a lot of development effort and get our five 9's latency under control.


I tried and gave up on getting Keycloak to use less memory. 500-1500 MB for a server with less than 10 concurrent users is ridiculous. And that's even using an external database.


What did you try? As a last attempt you can just check visualvm to see the actual memory use, add a few percent headroom and set that as heap size.


Much less of a problem in .NET (its GC tuning sits somewhere in between the two, especially when SRV GC + DATAS is in use, like in container scenarios, where Go is funnily unaware of limits set by cgroups and needs an external package to fix it). It does pre-allocate more memory than Go per se but in return yields much, much higher allocation throughput out of box. Java allows for even higher allocation throughput, having multiple more sophisticated GC implementations but as you said is not very good at reducing sustained RSS used by an application.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: