I need this change for sundry development work and experiments. The patch is relative to TR 3460 (Jan 6, 2010) and has not been tested with the Flash Player. Two issues I know are unresolved here are the GC::PreventImmediateReaping API (it's a no-op) and the quick reaping afforded by RC, on which the Player depends for a few things - this probably needs to be exposed as a new kind of API.

Rebased to TR 4901. Passes acceptance (D and R) and runs the benchmark suite (R) on MacTel32. Some FIXME / OPTIMIZEME work still.

Comment on attachment 455885 [details] [diff] [review] Patch, updated I should note that this is meant to apply on top of the patches for bug #576307, though I doubt the dependencies (if there are any at all) go deep.

It seems probable that with MMGC_DRC gone, ScriptObject::~ScriptObject (which is to say Traits::destroyInstance) is pretty much pointless, and can be omitted completely. There is a small amount of explicit freeing there for objects with a hash table, but if we could get rid of the need to call destructors for the bulk of the objects in the heap the benefits would be potentially great. We'll need to have a system for clearing the finalization bit for plain ScriptObjects but not for arbitrary subclasses; the patch for exact tracing has introduced that machinery already. Same appears to go for String::~String.

Note also that with DRC gone, a much faster write barrier, such as a card-marking barrier, should be possible.

Includes destructor optimizations as outlined in an earlier comment.

Once MMGC_DRC has been reintroduced, and the generational GC sits on top of that, then we can remove not just the conditionalized MMGC_DRC code from the system, but a lot of other code besides. This monster patch does so. (Note it does /not/ incorporate the previous patch or generational GC.) It is likely that a few things in this patch could be migrated back into the old patch and put under the control of MMGC_DRC, eg, destructors for HeapHashtable and PrecomputedMultinames (which are redundant without DRC), but I have not done so yet. If/when this gets to review I may try to split this patch along more logical lines. (For a handy map to the patch queue that's building up, see a future post on bug #516156.)

I should mention the few RC-related things that are not gone: - LIST_RCObject storage type, though it should never kick in - GCTests.cpp has some RCObject related stuff, it compiles but I haven't tried running it - There are some RCObject related selftests, they compile but I haven't tried running them. DRC, DRCWB, WBRC, WBRC_NULL, and RCObject are still defined by MMgc.h but not used by the VM or MMgc at this point, they're there for client code. RCObject is just an alias for GCFinalizedObject.

Rebased to account for the latest exact-marking changes.

Rebased to the latest underlying patches. My patch queue looks like this: markBitsRewrite (bug 575316) fastBitsTweak (bug 575316) deadCodeRemoval (bug 576307) exactMarking (bug 576307) mutatorChanges (bug 576307) rcEctomy (this bug) generationalGC (bug 576896) rcGone (this bug)

Hallelujah!

Comment on attachment 456408 [details] [diff] [review] Introduce MMGC_DRC (v4) This patch is part of the patch queue: http://hg.mozilla.org/users/lhansen_adobe.com/redux-revolution

Comment on attachment 456410 [details] [diff] [review] Remove MMGC_DRC from the system (v2) This patch is part of the patch queue: http://hg.mozilla.org/users/lhansen_adobe.com/redux-revolution

I did this experiment independently (because I forgot to check whether I could just apply Lars's pre-existing patch) and took a slightly different tack. Either/both should be evaluated as a step towards ripping out RC.