harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Date Sat, 29 Jul 2006 18:55:45 GMT
On 29/07/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> > 3) That it's necessary to put limits on a system that uses garbage
> > collection and should be able to release memory back to the OS at all?
> This point is quite moot.
> Most existing JVMs have sensible defaults,
> In DRLVM, I plan to do something similar for the defaults eventually, but
> have not got to it yet. Currently, it has hardcoded defaults of -Xms64m and -Xmx256m.

But the point is, this is a hardcoded default maximum of 256m for no
particularly good reason. Why should it not be infinity? In fact, it's
really a bad idea to have any non-infinte number by default, because
if your default is too small (which it will be for a number of
situations e.g. heavy server processing, massive Eclipse installs
etc.) then people *have* to override the default to allow their
applications to run.

> So, answering your question, if you do not want to put any artificial
> limit to the memory used by the java heap, then do not specify any -Xmx and -Xms
> options, and the JVM will decide itself.

The JVM will decide on another arbitrary default, though. If I don't
specify a maximum, I don't expect there to be a maximum. If I'm
running a J2EE system on a 3Gb PowerPC platform, why does the default
not allow me to run a J2EE server that takes advantage of all the
memory that I have? Why should it arbitrarily limit it to a small
percentage of what is currently available?

> However, if you *do* want to limit the amount of memory used for the JVM, then these
> options are very useful.

Agreed, when you do want to limit the resources (e.g. limiting each
process to a 1Gb chunk on a multi-processor, multi-core system) would
make sense. But if you *don't* want to limit it, you shouldn't specify
-Xmx and there should be no limit.

Let's face it, the only reason why J2EE servers (or indeed, Eclipse)
allow you to put in your own VM args for -Xmx is because the default
is too low for that particular use. There is absolutely no reason why
an upper limit is needed from a user's perspective, and the fact that
the VM chooses Math.random() as an upper limit for you is no help at

If you do specify -Xmx2056m then the VM will agressively take up all
that memory without releasing pages back to the OS, and for some VMs,
will actually try to request that much memory when the VM starts up.

Why not just request more memory when it's needed, and release it when
it's not? Then the only maximum is how much the operating system can

When was the last time you saw the message: "I'm sorry, Word cannot
load the document. You will have to re-run Word with -Xmx1024m in
order to be able to load it"


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message