Hacker News new | ask | show | jobs
by concerndc1tizen 405 days ago
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.
3 comments
homebrewer 405 days ago
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

link
gf000 405 days ago
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.

link
neuroelectron 404 days ago
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.
link
concerndc1tizen 405 days ago
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.
link
gf000 405 days ago
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.
link
neonsunset 404 days ago
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.
link