The http://wiki.apache.org/harmony/ClassUnloading wiki page is "Immutable". How can I contribute to it?
[Among other things, I'd like to add that the design can also potentially apply to SableVM and , and make other suggestions / changes.] Do I have to submit JIRA bugs? If yes, how do I make the patches? (svn diff?) Thanks for helping me! Etienne Aleksey Ignatenko wrote: > Actually there is one additional 4-th approach: > > *Mark and scan based approach *wich I described in the first letter. Java > heap trace is performed by VM Core and GC is not affected at all. > > So the list is: > 1. vtable objects( Aleksey ) > 2. per heap space/generation boolean marker on the classloader instance( > Etienne ) > 3. class reachability marker byte in vtable (Robin ) > 4. Mark and scan based approach. > > I agree that we need to structure all appraches somehow, like description > for every approach in wiki. > > Aleksey. > > On 11/10/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote: > >> >> Identifying an end to end alogirithm is of course necessary, and the >> discussions on the other thread are great. But what were we voting on >> here? >> My understanding was that we were voting on the approach of using: >> >> 1. vtable objects( Aleksey ) >> 2. per heap space/generation boolean marker on the classloader instance( >> Etienne ) >> 3. class reachability marker byte in vtable (Robin ) >> >> and not on three end-to-end algorithms since Robin's description was not >> one. I am OK if we now want to cancel the vote, but next time we vote >> on a >> technical issue it may be a good idea for the caller to summarize the >> contending solutions on the thread and then call for the vote. >> >> Thanks, >> Rana >> >> On 11/9/06, Weldon Washburn <[EMAIL PROTECTED] > wrote: >> > >> > 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 >> > >> > >> >> > -- Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
