On 8/1/06, Alex Blewitt <[EMAIL PROTECTED]> 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.
Thanks,
xiaofeng
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
