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: Re: [rant] Memory options in VM -- why is the default not 'unlimited'
Date Tue, 01 Aug 2006 02:24:33 GMT
On 8/1/06, Alex Blewitt <alex.blewitt@gmail.com> wrote:
> > The zones strategy you suggest may work well with apps that have a lot
> > of class loaders and allocate somewhat evenly across them, but I think
> > it may cause a lot of overhead.  Would your approach be generational?
> > Would you need Write Barriers for both references from other generations
> > as well as other Class Loaders?
> I've no idea if it would cause a lot of overhead. It might do. I'd
> imagine that each zone would have a nursery and mature generation, but
> possibly share some permanent generation.

This is close to a GC for multitasking JVM. :-) It's too early to know
if the idea is well applicable to the dynamic heap resizing.

> > If you were to have a Web Application, would you basically need a write
> > barrier for every string you allocate, since the String Class is loaded
> > in a parent class loader?  If so, this may cause more overhead than you
> > would want for the stated benefit.
> I suspect that if a write barrier was needed, this would quickly kill
> any of the efficiencies. Perhaps there would be some other
> optimisations that could avoid such things?

Write barrier doesn't necessarily kill any benefits. It's subject to
be measured if we have it implmented.

The basic idea I agree is, any hard limit is undesirable. It should be
dynamically adaptive according the system situation.


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