XPCNativeInterface::Mark(), Unmark() and IsMarked() don't do anything
any more, so anything that calls them can be deleted. This removes the
only use of XPCCallContext::CanGetInterface(), so delete that, too.
MozReview-Commit-ID: 4w3aPTVXNDI
There are four classes that call Root() on XPCNativeInterface, and
thus keep interfaces alive. Each of these gets converted to use a
RefPtr:
1. XPCCallContext. This could be on some kind of hot path, but the
FindMemberCall involves various string operations and hashtable
lookups, so adding a single AddRef shouldn't matter. One weirdness
here is that the context only roots the interface when |mState >=
HAVE_NAME|. With a RefPtr<>, this requires nulling out
mInterface. Fortunately, in most cases where it moves from rooting to
non-rooting, it already does this. The one case it does not is in
SystemIsBeingShutDown(), so my patch adds that.
2. XPCNativeSet. This holds an array of interfaces in a weird
placement new array at the end of the object. I wasn't sure how a
non-POD class would interact with the way the array is handled with
casting, so I manually AddRef and Release things put into or removed
from the array.
3. AutoMarkingNativeInterfacePtr simply becomes RefPtr<>. This is the
bulk of the patch, in terms of number of lines changed.
4. Similarly, the one AutoMarkingNativeInterfacePtrArrayPtr becomes
nsTArray<RefPtr<>>. This is the last use of the auto marking array
class, so I deleted it.
Here are some other notes on what the patch does:
- XPCNativeInterfaces are created with placement new. This requires a
special version of refcounting that calls DestroyInstance, defined in
the previous patch. The GetNewOrUsed methods used to explicitly call
DestroyInstance(), but with refcounting this is no longer needed.
- The Mark() etc. methods are gutted so they don't do anything and
mMarked is removed because it is no longer used. The methods will be
cleaned up in later patches in this bug.
- Interfaces are removed from mIID2NativeInterfaceMap in the dtor
instead of during sweeping, requiring an extra hash table lookup.
- All of the methods that can create a new interface (NewInstance,
GetISupports, GetNewOrUsed) now return an already_AddRefed<>, which
gives some static checking that we don't accidentally fail to hold
onto a newly created interface.
MozReview-Commit-ID: CrlH1ENAzvr
This adds a heap allocation in
XPCNativeScriptableSharedMap::GetNewOrUsed() on the fast
path. Hopefully that code is not hot enough for it to matter. I could
work around this if needed, but it would be ugly.
mNativeScriptableSharedMap has a weak pointer to
XPCNativeScriptableShared. I moved this removal from
XPCJSRuntime::FinalizeCallback() to the dtor.
There are two types of scriptable: one is a dummy one created in
GetNewOrUsed() to do a lookup, and the other is a fully filled out
one. The dummy one is not added to the hashtable, and may have had its
name stolen if we created a new scriptable. The latter makes it so
that you crash if you try to look it up in the hashtable anyways, so
this patch only looks up fully filled out scriptables.
This patch also removes MOZ_COUNT_CTOR/DTOR because they are not
needed for refcounted classes.
Stop destroying mScriptableInfo in XPCWrappedNative's
SystemIsBeingShutDown(), because that will end up destroying
XPCNativeScriptableShared, while their js::ClassOps are still in use
by JS objects. This matches the existing behavior, which does not
sweep these ScriptableShared during shutdown. (This came up in opt
xpcshell tests.)
MozReview-Commit-ID: GeG0pAYqXpR
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
I could clean up ArrayAutoMarkingPtr more, but it is going to be
removed entirely in bug 1288870.
MozReview-Commit-ID: Jyjc2ZfvF3i
--HG--
extra : rebase_source : d7954ab821722b26fe5fc4f5ddc319dd824c6879
This file is included in caps/, but it only uses generic JS things,
aside from a macro.
AccessCheck.cpp was bootlegging xpcprivate.h.
MozReview-Commit-ID: C6fGOFxsTvg
--HG--
extra : rebase_source : bd5e7bf9010acf83ccab8ce6cce77a557ad76196
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.
Also convert some NS_PRECONDITION in NativeSetMap.
MozReview-Commit-ID: IU9C5oXKvGK
--HG--
extra : rebase_source : 5fc36e95667d42a1c0cdfb9bbbf99a7ea008bf34
Also, use NS_PTR_TO_UINT32 instead of NS_PTR_TO_INT32 because it is not
undefined.
Get rid of the optimization of 0 ^ x which required a comment.
MozReview-Commit-ID: HPz5VgRnLN1
--HG--
extra : rebase_source : a4602964ff739c4e37aaa5883e6ed667bff1a963
XPCNativeSetKey has a huge comment about this weird hack it does,
where it tags the first 16 bytes with a magic value. The purpose of
this seem to be that PLDHashtable used to require that the Match()
operation handle both the desired "key" type and the actual entry type
(NativeSetMap::Entry in this case), with the latter needed for
resizing. However, that duality in the match operation has not been
needed since bug 374906, which landed in 2007, so this class can be
greatly simplified.
IsAKey() can be replaced with true, which simplifies some hash
operations.
