Re: Ranting about JVM's default memory limits...
On Sat, 2 Aug 2008, Mark Space wrote:
jolz wrote:
In a server environment, I can see that one really wants to limit memory
usage. It's a much more controlled situation, and professionally managed
(hopefully, relatively speaking).
I don't think the limit was ever implemented as a desired feature. It is
the oldest java bug resulting from GC's implementation.
I don't think "bug" is fair -- it's working as intended, and for server
environments it's probably a good idea.
For clients, "undesired feature" might be a good description.
"Boneheaded move" might be a better one.
I mostly agree with you - it's annoying to have to set maximum heap size
explicitly.
The problem is, in a garbage collected language, how do you set it
automatically?
In a manual memory management system, it's easy: if you run out of free
memory, you request more from the OS, because that's the only thing you
can do.
In a GC system, though, you always have the option of doing a collection.
So, if you run out of memory, do you grow the heap or collect? How do you
decide? You could say that you always collect, and only grow the heap if
that doesn't free enough memory, but that means your app will always be
running with nearly-full memory, which means it'll spend a lot of time
doing GC, which is not so hot. You could instead have a rule about having
a certain amount of free memory - say, if memory is more than a certain
percentage full after a full GC, grow the heap. But then you just replace
one parameter with another! I guess at least it's a parameter which is
more likely to have a sensible default that will work for all apps and all
points in history, which maximum heap size doesn't.
I'm not saying it can't be done, just that it's not trivial.
And i suppose this is really about the decision about when to grow the
heap, which java already has to make, not about maximum heap size.
tom
--
unstable orbits in the space of lies