In a server-side context the JVM tends to be the most memory efficient out of all platforms that make use of GC. Here's for example the comparison of Ruby MRI with JRuby, showing a massive difference in memory usage, and yet many Ruby developers choose to deploy their apps on top of JRuby precisely because of much better memory usage, which is why your reference to these benchmarks is basically useless:

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

It uses exactly as much memory as you specify. It would be pretty stupid to have plenty of RAM and NOT using it. With enough memory GC becomes essentially free, by not having to do any work.

Nonsense. I'm talking about the SAME data taking more memory to represent. Plus, all things being equal a larger memory space will take more time to GC, and GCs become longer, not shorter.

The JVM does things suboptimally in a number of ways. Object memory overhead is relatively high - typically 8 or 16 bytes per object, strings as UTF-16 (vs Go's UTF-8), etc. It really adds up, and funtional languages tend to churn lots of GC.

This is the first time I ever heard anybody complain about UTF-16, citing it as the reason for why the JVM consumes more memory, which is of course bullshit.

One reason for why JVM apps appear to consume so much memory is because the JVM allocates more memory than it needs. It does so because the garbage collectors are generational and compacting (well, CMS is non-compacting, but when the memory gets too fragmented, the VM does fallback to a stop-the-world compaction of memory). In a server context the JVM also does not release the free memory it has to the operating system, because allocating that memory in the first place is expensive and so it keeps it for later usage ... the result is that memory allocation on top of the JVM is as efficient as stack allocation, since all the JVM does is to increment a pointer, and deallocation of short-lived objects is nearly as innexpensive as stack unwinding, since the GC is generational and deallocates stuff in bulk. These capabilities come at a cost, as the GC also needs memory to move things around, but it's also memory well spent (e.g. Firefox has been plagued by memory fragmentation for years).

Speaking of Golang, it has some of the shittiest GCs in existence ... non-generational, non-compacting, non-concurrent and "mostly precise". Of course, it used to be fully conservative, which meant you could easily end up with really nasty memory leaks on 32bits systems, because the GC wasn't able to make a difference between Ints and pointers.

The only thing saving Go is the ability to work in many cases with the stack, alleviating the stress that the GC faces, but this low-level capability will also prevent it from having a good GC anytime soon, like the JVM has had for years.

And really, in terms of memory usage, you should see how the JVM's CMS or G1 behaves in production, as it makes all the difference. Our web-service (written in Scala) that's being hit by more than 30,000 requests per second that must be served in under 100ms per request, was at some point hosted on Heroku, using only 8 instances, instances which have less than 400 MB of usable RAM. It was absolutely superb seeing it in action, as the processes themselves were not exceeding 200 MB of real usage - Heroku even told us that we are costing them more than we are paying them.

So yeah, you can talk bullshit about strings being UTF-16, but the real wold disagrees.

> strings as UTF-16 (vs Go's UTF-8), etc.

Strings aren't traced, so that has no impact on GC time.

It does, however, impact memory usage quite substantially if your data is string-heavy, which most web-apps are.