Robert O'Callahan wrote:

> What's the impact of using DRC for everything in our own code?

I'll summary what I learned from Jason on IRC:

* RCObject is an early-collection optimization: when an RCObject refcount
goes to zero, it is placed in the ZCT (zero-count table)... at some frequent
interval, MMGc scans the stack to make sure there are no stack pointers to
ZCT objects and then collects them. This collection is shallow and fast.

* Tamarin uses RCObject for all JS objects, including strings.

The costs of RCObject:

* the objects keep an extra int member
* if threadsafety is needed, we need atomic increment/decrement
* cycles between RCObjects or any references to RCObjects from GCObjects
will not be collected until a "standard" GC
* Any object that holds a reference to an RCObject (a DRCWB) has to have a
finalizer

>From reading code, I've also gleaned that the current DRCWB system assumes
that you have a toplevel pointer, not an internal pointer like we normally
keep in XPCOM. To work around this you either have to
dynamic_cast<RCOBject*>, which requires RTTI and may not be cheap (needs
measurement), or keeping virtual functions, which means AddRef/Releease.

I tend to think that the costs of RCObject for general "XPCOMGC" use are too
high: in particular, I think we want to have pervasive cycles between DOM
objects: parent<->children DOM nodes as well as node<->document references.

--BDS
_______________________________________________
dev-tech-xpcom mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-xpcom

Reply via email to