Open Bug 1548685 Opened 6 years ago Updated 2 years ago

Support Rust in the cycle collector

Categories

(Core :: Cycle Collector, task, P3)

task

Tracking

()

People

(Reporter: mccr8, Unassigned)

References

(Blocks 2 open bugs)

Details

I don't have any plans to work on this, but I thought it would make sense to file a bug about it so we can gather examples of places where it would have helped. Bug 1546287 is an instance where some Rust code is held alive only by JS, and the Rust code itself holds alive a callback. As you'd expect, without help from the cycle collector this is a very leak-prone pattern.

Conceptually, it should be possible for Rust code to participate in cycle collection.

The two major piece of an API for the cycle collector is something are:

  • A Traverse method, that will call some methods on a callback that gets passed in, to tell the CC what the object holds onto, plus some information about the object itself, like the name and refcount.
  • An Unlink() method that nulls out any references the object holds onto. It also needs to implement Root() and Unroot() methods that keep the object from going away, even if all other references to the object are nulled out.

We need to add some methods along the lines of NoteNativeRoot and NoteNativeChild, or NoteXPCOMRoot and NoteXPCOMChild, depending we'd call from C++ into Rust.

Type: defect → task
Priority: -- → P3

Another subtler property that the cycle collector needs is a "canonical form" for pointers: every pointer to an object that is passed in to the cycle collector must be bit-for-bit equal. For XPCOM objects, due to inheritance this is not automatically true, so the CC uses a hacked up QI thing to get a canonical pointer. For "Native" and JS CCed objects, the pointers just have to have this property always.

Since CanSkip* optimizations are rather important for well behaving CC, those should probably be available to Rust side from the beginning.

Somehow Rust side, or the layer between CC and Rust, needs to use nsCycleCollectingAutoRefCnt objects for ref counting. (It is used to optimize out most of the refcounting overhead in cycle collectable objects)

Participants have also DeleteCycleCollectable, that is needed by snow-white killer. Objects must stay alive until it is called.

Blocks: 1302212
Severity: normal → S3
Component: XPCOM → Cycle Collector
You need to log in before you can comment on or make changes to this bug.