1733674 - Add an annotation mechanism for declaring members to be GC-safe at the end of a destructor

Status: NEW

(Core :: JavaScript: GC, enhancement, P3)

Description

[Steve Fink [:sfink] [:s:]]

Consider:

class Owner {
  RefCnt<SomeType> mFoo;
};

Owner::~Owner() {
  DeferredFinalize(mFoo.forget());
}

The intention is: we don't want to finalize mFoo immediately, because it might GC and we don't want ~Owner to GC (perhaps so Rooted<Owner> doesn't cause problems when it goes out of scope). But the analysis will complain because after the body of ~Owner, it will tear down the member variables, and ~RefCnt<SomeType> if its ref count goes to zero will then do SomeType.Release() which might GC. The DeferredFinalize (or perhaps doing a DelayedDispatch to some destroyer runnable) ensures that this will not happen; the GC will be delayed to a safer time. But the analysis doesn't know this.

This bug proposes making it so JS_HAZ_VALUE_IS_GC_SAFE(mFoo) may be used to inform the analysis that mFoo is now empty and will never trigger a destructor. That annotation is ordinarily used to say that a local variable doesn't contain a GC pointer even though its type says that it potentially could, so perhaps the annotation should be named differently as this is really a different meaning.

Alternatively, the analysis could infer this from the call to forget(), and then no annotation would be needed.