One thing not raised in your proposal is what to do with objects that
are currently *not* refcounted. Two good examples are strings (nsString
and friends) and arrays, for example nsTArray.
If we turn all currently refcounted objects into GCFinalizedObject, then
any nsString and nsTArray inline members will get their destructor
called when the hosting object is destroyed. Would that be a big
overhead? The devmo docs discourage GCFinalizedObject.
An alternative is to make nsString and nsTArray inherit GCObject, and
make them allocate their internal buffers using GC::Alloc.
However this doesn't fully work for nsTArray since we would still not be
finalizing the objects in the array. We could of course say that you're
not allowed to stick objects that need finalizing in nsTArray, but that
would probably break a good number of current users, for example
PathExpr::mItems in txExpr.h. This contains a number of PathExprItems like:
class PathExprItem {
public:
nsAutoPtr<Expr> expr;
PathOperator pathOp;
};
One way to fix this one example would be to make PathExpr::PathExprItem
and Exprs be GCObjects too, and so on. However with this strategy we
would likely be forced to convert a very large number of objects into
GCObject. This certainly sounds doable, but it seems like a lot of work,
much of it risky.
We can't simply make nsTArray a GCFinalizedObject, for two reasons.
First of all we don't really want to pay the overhead of a vtable
pointer. This class is just 4 bytes big when empty, so it would double
in size. Second, nsTArrays often appears as inline members in other
classes. If such classes are GCObjects then the garbage collector will
not be able to detect the inline GCFinalizedObject and finalize it.
/ Jonas
Jason Orendorff wrote:
> On Aug 28, 9:34 am, Jason Orendorff <[EMAIL PROTECTED]> wrote:
>> More on this in a few hours.
>
> I don't think there's such a thing as a contract that (a) is simple,
> (b) is
> efficient, (c) supports GC, (d) supports refcounting for objects that
> want it,
> and (e) really hides memory management implementation details. So
> there will
> be design tradeoffs here.
>
> For the sake of having a concrete proposal to chew on, I propose the
> following:
>
> * Drop AddRef and Release from nsISupports.
>
> * Require all XPCOM objects to be MMgc GCObjects or
> GCFinalizedObjects,
> allocated from the same GC allocator as all JavaScript objects.
>
> Read more about MMgc here:
> http://developer.mozilla.org/en/docs/MMgc
>
> * Change any code that depends on objects being destroyed in a
> specific
> order, or at a specific time, to use some explicit means of
> ensuring that
> it really happens that way, rather than depending on reference
> counting.
>
> * Use static tools to replace our uses of nsCOMPtr and friends with
> the MMgc
> equivalents, and replace nsISupportsWeakReference with MMgc
> GCWeakRefs.
>
> * Add thread-safety to MMgc using the Spidermonkey request model.
>
> * Delete the cycle collector.
>
> How did I do? This proposal nails goal (c), does quite well on (a)
> and OK on (b),
> and ignores goals (d) and (e). Maybe you can do better.
>
> I'll be working on the following bug quite soon, so now is the time to
> speak up.
>
> Bug 393034 - Allocate DOM objects using MMgc
> https://bugzilla.mozilla.org/show_bug.cgi?id=393034
>
> -j
>
_______________________________________________
dev-tech-xpcom mailing list
dev-tech-xpcom@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-xpcom
