harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Date Sat, 29 Jul 2006 12:35:03 GMT
This makes much sense to me, Alex, I mean a dynamic heap size. In my
understanding, there are following reasons to explain current hard
limit status:
1. the GC design usually hopes to have continuous memory space. The
dynamic heap increase and decrease may have difficulty to interact
with OS so as to keep the GC heap continuous.
2. there is an assumption that the JVM fully controls its heap of
given size, hoping they all resident in physical memory. The GC
algorithm sometimes requires full-heap walking, but doesn't want to
incur many page faults.

Basically these are because OS and JVM don't always cooperate
friendly. But this is changing. See links below for your reference
[1][2]. And I support to have a dynamic heap resizing in Harmony in
the future.

[1]http://www.bea.com/content/news_events/white_papers/BEA_JRockit_wp.pdf
[2]http://www.cs.umass.edu/~emery/pubs/automatic-heapsize-ismm2004.pdf

Thanks,
xiaofeng

On 7/29/06, Alex Blewitt <alex.blewitt@gmail.com> wrote:
> I believe this might be of general interest and worth debating here,
> from a post on EclipseZone:
>
> http://www.eclipsezone.com/eclipse/forums/t77021.html#92035043
>
> "Am I the only one that's frustrated that:
>
> 1) The -X options even exist at all. After all, they're so standard
> now (e.g. -Xmx256m) that the point of calling them 'non-standard'
> options is pretty much laughable.
>
> 2) That they felt the need to build another level of non-non-standard
> into command line options such that -XX is even necessary
>
> 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?
> I mean, what is the point in artificially limiting the size of these
> anyway? I can see that there may be optimal tweaks that you'd want to
> perform on some server systems (e.g. initial sizes) and maybe for some
> constrained systems the maximal size too; but why isn't the default
> 'unlimited'? The only time I should see an OutOfMemoryError is when
> the OS refuses to give any more memory to the app, not when some
> artificial hard-coded limit is reached in some random defaults
> hard-coded into a C file. Name one other language/system/application
> that has such an arbitrary self-enforced maximal non-unlimited default
> built in. Heck, even OS resources (like ulimit or #file handles) are
> specified at the OS, not the application, level.
>
> With any luck, open-source VMs like Harmony won't be as anal with
> their memory management, and the default for such things will be
> unlimited. Just one of the benefits of an open-source version; you
> won't have to be artificially cramped by random decisions at the VM
> level."
>
> Alex.
>
> ---------------------------------------------------------------------
> 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
>
>

---------------------------------------------------------------------
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


Mime
View raw message