2 ms·
The GC comment was true of older versions of the JVM but newer versions are much better. And by newer I mean versions released in the last 5 years or so. So not
by thu2111 6y ago
The GC comment was true of older versions of the JVM but newer versions are much better. And by newer I mean versions released in the last 5 years or so. So not that new.
There are one or two knobs left but those are fundamental to GC technology and it's not even obvious they're bad to have. GC lets you trade off memory against CPU time in ways manual memory allocation does not. You can throw memory at your program and it'll run faster, or you can constrain it and it'll run slower, but that's not a decision the developer can always reasonably make. It's in some ways inherently an ops/deployment/end user thing.
Other GCd languages either:
1. Have knobs too (Go/.NET both have knobs), just usually not very good ones.
or
2. Are so slow (Ruby, Python) that GC tuning is really the least of your worries and they just don't expose it at all.
or
3. Are JavaScript, in which case everyone pretends that running a VM designed exclusively for laptops and mobile phones on the server isn't a giant waste of resources. V8 doesn't do GC tuning because its only real customer is web browsers where users can't do that, and heaps are small anyway.
Java ended up getting a totally unfair rap about GC because it actually was fast enough that GC performance mattered, and was interested in power users on the server where exposing knobs can make sense. Other competitors don't even try, but this doesn't make them better. After all, nothing stops you just ignoring the knobs and plenty of users do exactly that.