[gclist] Re: newbie:why not cyclic refcount?

[cppljevans@earthlink.net]

Would anyone at gclist care to join this
discussion in netscape.public.mozilla.xpcom?

------------------------------------------------------------------------------

This message was forwarded to you from Deja.com by cppljevans@earthlink.net.
Deja.com offers free consumer information, including ratings and reviews on
thousands of products and services.  Before you buy, visit 
http://www.deja.com/
------------------------------------------------------------------------------

(beginning of original message)

Subject: Re: newbie:why not cyclic refcount?
From: cppljevans@my-deja.com
Date: 2000/03/19
Newsgroups: netscape.public.mozilla.xpcom
In article <beard-C8C0C0.11061815032000@news.mozilla.org>,
Patrick Beard <beard@netscape.com> wrote:
> In article <8a62ag$rfh$1@nnrp1.deja.com>, cppljevans@my-deja.com
wrote:
>
> > Instead of the current reference counting method, why not use the
cyclic
> > reference counting method, described in:
> >
> > Rafael D. Lins
> > "Cyclic reference counting with lazy mark-scan"
> > _Information Processing Letters_, 44(4):215-220, 1992
> >
> > Wouldn't this avoid the problem with "cycle of ownership" mentioned
> > in http://www.mozilla.org/projects/xpcom/Ownership.html?
>
> I've read all 3 of his papers on the subject, and there's a
fundamental
> reason why we can't adopt it. XPCOM doesn't expose any mechanism to
> allow a cycle scanner to obtain all of the references a given object
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> contains, nor does it provide direct access to each object's reference
  ^^^^^^^^
Wouldn't the method in Detlef's article( "Garbage collection and runtime
typing as a C++ library" in USENIX C++ Conference, Portland, Oregon,
August 1992) provide this?

> count field.
>
> To make this work, we'd need each class in the system to implement an
> interface like this:
>
> /**
> * Provides a way for a cycle scanner to walk a graph of references
> * to XPCOM objects, all of which must implement this interface.
> */
> class nsIReferences : public nsISupports {
> public:
....skipping
> };
>
> The problem with this, is that EVERY class in XPCOM has to implement
> this interface, or the whole thing breaks down. In the past, I've
> experimented with using pointers to data members to implement such a
> mechanism generically, but I don't think it's worth the effort.
>
Wouldn't adding this interface to nsiSupports solve the problem?
However, in addition to the reference count, the object's color would
also be needed.  The interface could be simplified some by just
using a virtual function such as:

  virtual unsigned push_COMPtr(stack<nsCOMPtr*>&aStk){ return 0;}

which would push the internal pointers contained in the object onto
aStk.  For those objects not containing any internal pointers, this
version of the function would suffice.  For others,  the method in
Detlef's article could be used to calculate the internal pointer map
which would then be used to implement push_COMPtr.


Sent via Deja.com http://www.deja.com/
Before you buy.


(end of original message)
------------------------------------------------------------------------------

You can view this message and the related discussion by following this link:
http://www.deja.com/dnquery.xp?search=thread&svcclass=dnserver&recnum=%3c8b1pdk$uta$1@nnrp1.deja.com%3e%231/1
We hope to see you soon at Deja.com.
Before you buy.
http://www.deja.com/