The future of XPCOM memory management (restarting thread from m.d.t.xpcom)

[rocal...@gmail.com]

Jason wrote:
> Benjamin also thinks DRC is, in fact, avoidable in XPCOM-- we'll use a
> GCObject wrapper when passing DRC script objects to XPCOM code.

This would have the effect of delaying the deallocation of any such
DRC script object until at least the next GC. If we're willing to do
that, then there's an easier way: we can just set the DRC object's
refcount to its saturated value. No wrapper required.

Rob

[rocal...@gmail.com]

I posted on my blog about the general problem of collecting cycles
across memory-manager boundaries, and wrote in more detail about what
I think is the least invasive way to achieve it:
http://weblogs.mozillazine.org/roc/archives/2007/09/federal_governm.html

Rob

[rocal...@gmail.com]

Jonas asked on IRC how this would work with Python's cycle collector,
which uses trial dereferencing:
http://arctrix.com/nas/python/gc/

First, create a set of references to Python objects that may be
referenced by foreign runtimes. When a reference is added to this
"externally referenced" set (e.g. because an object is being passed to
a foreign method), addref the object.

Interface global GC with Python's cycle collector as follows:
During "Stop The World":
> 1. For each container object, set gc_refs equal to the object's reference count.
> 2. For each container object, find which container objects it references and decrement the referenced container's gc_refs field.
2b. For each container object in the "externally referenced" set,
decrement its gc_refs field.
2c. Initialize a "new externally referenced" set to empty.

During "Mark":
> 3. All container objects that now have a gc_refs field greater than one are referenced from outside the set of container objects. We cannot free these objects so we move them to a different set.
> 4. Any objects referenced from the objects moved also cannot be freed. We move them and all the objects reachable from them too.

This is equivalent to marking all objects with gc_refs greater than
zero (I think "greater than one" is a typo). Whenever Python moves a
container object to the "retained" set, it should request marking of
any foreign-owned child objects of the container.

4b. When a foreign runtime requests marking of a Python container
object, we move it and all the objects reachable from it to the
retained set.
4c. When a foreign runtime requests marking of a Python object, add it
to the "new externally referenced set". If it wasn't already in that
set, add a reference to it.

During "Sweep":
> 5. Objects left in our original set are referenced only by objects within that set (ie. they are inaccessible from Python and are garbage). We can now go about freeing these objects.

5b. Decrement (and possibly free) the refcount of any Python non-
container object that is in the old "externally referenced" set.
5c. Replace the old "externally referenced" set with the new one.

Rob

[rocal...@gmail.com]

On Sep 11, 11:26 am, "rob...@ocallahan.org" <rocalla...@gmail.com>
wrote:

> Interface global GC with Python's cycle collector as follows:

I don't know how palatable such changes would be to Python
maintainers, but they at least have the nice feature that if no
external references are present (in either direction), none of this
new code does anything. That's quite a big difference from, say,
asking them to use MMgc. And it's pay-as-you-go; if you use just a few
external references, then there's just a little bit of extra work (and
just a little bit of exposure to potential bugs/regressions).

Rob