The Cycle Collector currently lives as part of the XPCOM module, but the
XPCOM module owners/peers are not the people who do the majority of the
work on the Cycle Collector. Also, the people who do the majority of
the work are *not* XPCOM owners/peers, which makes it unclear who should
review Cycle Collector code etc.
I'm proposing we create a new module for the Cycle Collector, with the
details listed below. This module will be a bit different than most
whereas the cycle collector code currently sits in the midst of the rest
of the XPCOM code, not in its own directory (which is of course
something we can change down the road). Also, critical pieces of the
Cycle Collector lives outside of the core Cycle Collector code itself,
most notably in XPConnect, but also in various traverse/unlink functions
throughout many other modules.
On Tue, Sep 4, 2012 at 5:05 PM, Johnny Stenback <j...@mozilla.com> wrote:
> The Cycle Collector currently lives as part of the XPCOM module, but the
> XPCOM module owners/peers are not the people who do the majority of the
> work on the Cycle Collector. Also, the people who do the majority of
> the work are *not* XPCOM owners/peers, which makes it unclear who should
> review Cycle Collector code etc.
> I'm proposing we create a new module for the Cycle Collector, with the
> details listed below. This module will be a bit different than most
> whereas the cycle collector code currently sits in the midst of the rest
> of the XPCOM code, not in its own directory (which is of course
> something we can change down the road). Also, critical pieces of the
> Cycle Collector lives outside of the core Cycle Collector code itself,
> most notably in XPConnect, but also in various traverse/unlink functions
> throughout many other modules.
I wonder -- should the description should say anything about parts of the module living outside the cycle collector. One example might be what we did for browserID, where the description notes this (see the last bullet point below)
Description:
-- Server Code;
-- Server deployment (during labs / prototype phase); and
-- navigator.id.* API across Mozilla codebases (desktop, mobile, WebRT,..)
> On Tue, Sep 4, 2012 at 5:05 PM, Johnny Stenback <j...@mozilla.com> wrote:
>> The Cycle Collector currently lives as part of the XPCOM module, but the
>> XPCOM module owners/peers are not the people who do the majority of the
>> work on the Cycle Collector. Also, the people who do the majority of
>> the work are *not* XPCOM owners/peers, which makes it unclear who should
>> review Cycle Collector code etc.
>> I'm proposing we create a new module for the Cycle Collector, with the
>> details listed below. This module will be a bit different than most
>> whereas the cycle collector code currently sits in the midst of the rest
>> of the XPCOM code, not in its own directory (which is of course
>> something we can change down the road). Also, critical pieces of the
>> Cycle Collector lives outside of the core Cycle Collector code itself,
>> most notably in XPConnect, but also in various traverse/unlink functions
>> throughout many other modules.
That sounds very reasonable to me, we could make the description be
something like:
Description:
-- The XPCOM/JS cyclic reference collector itself;
-- The integration code between the cycle collector and the JS GC in
XPConnect; and
-- The various trace, unlink, and other cycle collector hooks spread
throughout the code.
> I wonder -- should the description should say anything about parts of
> the module living outside the cycle collector. One example might be
> what we did for browserID, where the description notes this (see the
> last bullet point below)
> Description:
> -- Server Code;
> -- Server deployment (during labs / prototype phase); and
> -- navigator.id.* API across Mozilla codebases (desktop, mobile,
> WebRT,..)
> mitchell
> On 9/5/12 2:53 AM, Jonas Sicking wrote:
>> On Tue, Sep 4, 2012 at 5:05 PM, Johnny Stenback <j...@mozilla.com> wrote:
>>> The Cycle Collector currently lives as part of the XPCOM module, but the
>>> XPCOM module owners/peers are not the people who do the majority of the
>>> work on the Cycle Collector. Also, the people who do the majority of
>>> the work are *not* XPCOM owners/peers, which makes it unclear who should
>>> review Cycle Collector code etc.
>>> I'm proposing we create a new module for the Cycle Collector, with the
>>> details listed below. This module will be a bit different than most
>>> whereas the cycle collector code currently sits in the midst of the rest
>>> of the XPCOM code, not in its own directory (which is of course
>>> something we can change down the road). Also, critical pieces of the
>>> Cycle Collector lives outside of the core Cycle Collector code itself,
>>> most notably in XPConnect, but also in various traverse/unlink functions
>>> throughout many other modules.
>>> Name: Cycle Collector
>>> Description: The XPCOM/JS cyclic reference collector
>>> Owner: Andrew McCreight
>>> Peers: Peter Van der Beken, Olli Pettay, David Baron
>>> Source Dir(s):
>>> http://hg.mozilla.org/mozilla-central/xpcom/base/nsCycleCollector.{cpp,h},
> That sounds very reasonable to me, we could make the description be
> something like:
> Description:
> -- The XPCOM/JS cyclic reference collector itself;
> -- The integration code between the cycle collector and the JS GC in
> XPConnect; and
> -- The various trace, unlink, and other cycle collector hooks spread
> throughout the code.
> I'm proposing we create a new module for the Cycle Collector, with the
> details listed below.
I have made this change in Modules/Core. For now I have listed Core::XPCOM as the bugzilla component, since I'm not sure that we need another component.
