It looks like I called for a vote too soon. The continuing discussion on class unloading design is uncovering many important issues. This is excellent as it is much better to deal with design issues at this stage rather than during implementation.
I propose the following: 1) Cancel the current vote on design. 2) Someone put together a complete class unloading design based on Etienne/Robin's approach. Include pseudo code and post to harmony-dev. 3) We call for a new vote once the comments on the documented design indicate it is ready. On 11/8/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Pavel Pervov wrote: > Really BIG -1 from me. > > As Aleksey (Ignatenko) described in original thread, j/l/Class'es and > j/l/ClassLoader's are always available in rootset, so even if no objects > of a class exist, this class will be reachable. > > Actually, some sort of class unloading prototype exists in DRLVM code, > which > implements the scheme, which is very close to what is currently voted. It > was integrated with GC v4 and is not supported by other GCs. This prototype > traces up to class loader. Robin's approach is way faster then prorotype > is. > > Unfortunately, that approach requires up to 3 GC cycles to complete in > DRLVM. In a full-heap STW collector, my proposal would require 1 GC to collect unused classloaders. In a generational STW collector, 1 full-heap GC, and would depend on the particular invariants enforced by an incremental/concurrent collector, but would be 1 complete "cycle" of any of the standard algorithms (I guess up to 3 GCs if the sweeps happened at the wrong places). > BTW, voted approach does not describe "proof-of-full-collection" algorithm > (at least I didn't find one). The only one I think of is > full-heap-collection, which _requires_ STW. My approach simply requires the underlying collector to have a notion that periodically it can say that 'every reachable object allocated since time 't' is now marked reachable. If the class-unloader can ensure that one full epoch of this invariant has passed, then it can safely perform unloading. > Although "automatic anloading" brings some additional requirements for GC > (weak roots (references) support and pinned allocation), it is proven to > work (patch available) and, also, is the most natural algorithm for DRLVM. What is the run-time cost of it ? And where is it described ? I was only aware of Etienne's proposal as a full class-unloading scheme. > With the best regards, -- Robin Garner Dept. of Computer Science Australian National University
-- Weldon Washburn Intel Enterprise Solutions Software Division
