[snip]
> Alexey,
>
> it looks like what you are thinking about is *concurrent* collector,
> and concurrent garbage collections brings substantial complexity
> even without class unloading.

Salikh,

You are correct. Maybe I'm running ahead of the train, but my concern
is that "scalability" of unloading design is not the last criteria.
The decision we'll do now should not strike back at us in some months.

> However, the design we were discussing was for *stop-the-world* garbage
> collectors, because this is the only thing currently supported by DRLVM,
> and all existing GCs are stop-the-world.

I'm kinda optimistic on gcv5 progress, feeling that concurrent
collection is not improbable to be workable before H2/2007 :)

>
> So, the correctness of unloading algorithm can easily be proved if we consider
> that the "final unloading" collection is a full heap collection,
> i.e. both nursery and mature space is collected.
Yes, things are more or less clear for the case of STW GC so we can
concentrate on scripting more detailed technical proposal...

[skip]