1801214 - Make Hold/DropJSObjects less error prone

Status: NEW

(Core :: Cycle Collector, enhancement)

Description

[Olli Pettay [:smaug][[e-mail]]]

We've had couple of times errors like in https://bugzilla.mozilla.org/show_bug.cgi?id=1800470 where Hold/DropJSObject is called in the ctor/dtor of the base class, and another CC class extends that class. CC then later asserts that the participant is wrong.

Comment 1

[Andrew McCreight [:mccr8]]

Yeah, I like having HoldJSObjects in the ctor because it means you can't forget to do it, but using QI in the parent class ctor doesn't work because the vtable is for the base class still. Using the type at the call site doesn't work even outside of the ctor. (We do this for non-nsISupports CC'd things, but we don't support inheritance there at all.)

Comment 2

[Andrew McCreight [:mccr8]]

In the previous case I looked at, the base class was never instantiated, so you could just put the hold in the subclasses and not the base class.

Comment 3

[Andrew McCreight [:mccr8]]

never instantiated directly, rather, but only as a superclass

Comment 4

[Andrew McCreight [:mccr8]]

One possibility would be to lazily determine the participant, but the holder table structure is already rather complex to improve GC performance. I'd also worry about dealing with edge case scenarios like what if you are inside a ctor for a superclass and you try to allocate a JS object and you GC and then the GC tries to resolve the participant. At least with the current setup, you find issues every time.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

In this (bug 1800470) case the base class can be instantiated. Or the subclass.