Re: Ranting about JVM's default memory limits...
On Sun, 3 Aug 2008, Daniele Futtorovic wrote:
On 03/08/2008 08:18, Mark Space allegedly wrote:
Daniele Futtorovic wrote:
@see RFEs
"Can we eliminate the -Xmx max heap 'glass ceiling'?"
<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4408373>
QUOTE:
"Evaluation
It is unlikely that we will eliminate the -Xmx ceiling any time soon.
We get a lot of performance out of having side data structures that
are 1-to-1 with the heap, so we need the heap to be contiguous.
We know how to build "chunked" heaps, but the performance is thought
to be significant (10%?), to allow for a feature that you mostly
won't use if we can size the heap correctly from command line.
This is not high on our list."
ENDQUOTE
This is a bullshit reason. These people need to earn their flaking
salaries and learn how to resize the heap efficiently.
This is very bad. I regularly run the incremental garbage collector in
desktop apps because I think it gives far smoother performance. Sun
says the incremental garbage collector also looses about 10%
throughput, but I don't mind a bit. The trade off for me while using
the apps is well worth it.
The idea that Sun knows better than us how we want our apps to run is
just plain silly. I wish they'd get off their high horse and implement
this. Even a 20% loss of through put would probably acceptable.
Quite correct.
I especially like the part about "won't use [it] if we can set the heap
correctly from the command line." Hello!? McFly!? Requirements
change! What's a common file size today is trivial tomorrow, and
tomorrow what's impractical today is common.
Is there really a significant class of applications for which the
possibility to grow their heap ever larger is a sine qua non? I can't
really think of any.
Easy. Any application which handles multiple large documents - an image
editor, graphics tool, CAD package, whatever. As machines get more
powerful, you want to be able to handle more documents at once, and
bigger, more complicated documents. You want the amount of heap used to
grow accordingly.
Note that we're not talking about apps whose heap grows constantly over
time. That's a red herring. We're talking about apps where the heap grows
to some asymptotic limit, but where that limit is not known at build-time.
You're saying that systems change and so forth. But the size of your
data structures doesn't
Perhaps not, but the number of them does!
tom
--
unstable orbits in the space of lies