[revelation]

Java has its own heap so the memory usage, certainly for a server VM, doesn't necessarily correspond to actual application memory use.

(Also, of course, your main server uses "up to" 5 GiB? That's fucking great. Until it goes beyond 64 GiB, who even cares. Work on something that has a worthwhile monetary return..)

[paulddraper]

Assuming it is heap space: that just prompts the question why is there heap space so large?

[the8472]

The default sizing policies optimize pause times, throughput and only as tertiary goal for footprint.

Additionally people often tune the JVM to avoid some startup costs which includes fixed heap sizes which prevents the JVM from returning memory to the OS.

On top of that there often are just plain bad programming practices like deserializing large files into memory instead of streaming them. I suspect that rust also attracts more performance-conscious developers that avoid such things. Or maybe it is applied in projects where "throw more hardware at it" is not a cost-effective measure and investing in more developer-hours is appropriate.

[revelation]

It answers the question: you can't just look at gross native memory usage and conclude the Java app is 100x less efficient, that value simply doesn't tell you a lot. Server VMs are commonly configured to use gigabytes of RAM from the get-go, and when the initial VM heap is full, Java will not make small adjustments but instead grab a big chunk, and when that is no longer needed, it is often reluctant to release that additional memory.

I have no doubt that a Rust app will generally be more memory-efficient, but ultimately for server applications that is really not something a lot of people care about because of the incredibly low cost of "just buying more".