XPCNativeScriptableInfo is now a very thin wrapper around nsIXPCScriptable, and
it uses manual memory management. Removing it simplifies things quite a bit.
In particular, when setting XPCWrappedNative::mScriptable in
XPCWrappedNative::WrapNewGlobal() and XPCWrappedNative::Init() we no longer
have to worry about sharing the XPCNativeScriptableInfo object with the proto.
And XPCWrappedNative::{Init,Destroy}() have similar simplifications.
This patch is similar to bug 1288870.
Strong references:
- XPCCallContext::mSet: Like XPCNativeInterface, this only roots it
when |mState >= HAVE_NAME|, and again this only requires changing
SystemIsBeingShutDown().
- XPCWrappedNativeProto::mSet and XPCWrappedNative::mSet. These become
RefPtrs.
- stack: AutoMarkingNativeSetPtr become RefPtr<XPCNativeSet>. This
lets me eliminate some uses of AutoJSContext. This is the bulk of the
patch.
Weak references:
- mNativeSetMap. This reference gets cleared in the dtor. This
requires bug 1290239 to actually find the entry for removal.
- mClassInfo2NativeSetMap. The reference is in the value for this hash
table, and we don't have the key in the set dtor. Fortunately, the
only code that adds to this table is
XPCNativeSet::GetNewOrUsed(nsIClassInfo* classInfo), which in turn is
only called by GetNewOrUsed(nsIClassInfo* classInfo). This code
creates a new XPCWrappedNativeProto, which (with my patch) holds a
strong reference to the set that has been added to the table. This set
is never changed or released until the dtor for the proto, which calls
ClearCacheEntryForClassInfo(), removing the entry from the
hashtable. Thus, the lifetime of the set is always going to be longer
than the lifetime of the entry.
Other notes:
- Like XPCNativeInterface, this class uses placement |new| that
requires a special destruction function, which with my patch is hidden
away in the refcounting code.
- This patch delete a bunch of marking/sweeping code from
XPCJSRuntime::FinalizeCallback(), because the lifetimes are managed by
the refcounting now. Some of the marking code is left behind to be
cleaned up in a later patch.
- I didn't see any methods that had XPCNativeSet** outparams.
- MOZ_COUNT_{CTOR,DTOR}(XPCNativeSet) is not needed because it is now
refcounted.
MozReview-Commit-ID: 7oTorCwda1n
Like part 2, this patch is to work around a false GC hazard in
~XPCNativeInterface in part 4. This hazard is around the return value
of WrapperFactory::PrepareForWrapping(), because ~XPCCallContext might
call ~XPCNativeInterface. The fix is to pass the return value into a
mutable handle. Unfortunately, this function is used in the JSAPI, so
JS minor engine changes are also needed.
MozReview-Commit-ID: GwFxmrXFXmb
The basic idea is that we assume the invariant that the "obj" argument is never
gray if "existing" is null (and add asserts to that effect). Starting from that
assumption, terrence and I audited all the return paths to ensure that gray
objects are never returned. We found a few places, generally after crossing
compartments with UncheckedUnwrap, where we could have gray things and inserted
corresponding calls to ExposeObjectToActiveJS.
If "existing" is passed in, all bets are off: both "obj" and "existing" can be
gray and can get returned from here. But the only caller that passes "existing"
doesn't allow the return value to escape, so it's actually safe to do this.
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Possible because both |new| and PLDHashTable initialization are infallible now.
I had to use NS_ABORT_OOM for a couple of the maps that use js::HashTable,
which still has fallible initialization. There were a couple of uses of those
maps that weren't protected by null-checks, so we would have got crashes anyway
if they had OOMed.
