The rejection handling state will be required even without devtools being open once projection rejection tracking events[1] are implemented, so it should always be tracked on the Promise itself. The other debugging state will be moved into a debug-only object referenced via a slot on Promise.
MozReview-Commit-ID: LM10qruLDxz
A Promise can only have either a list of reactions, if it's pending, or a result/reason, if it's resolved.
This gets us down to 3 non-debug-info slots. If we now move the debug info into its own object and only allocate that when the debugger is open, Promise instances only need 4 slots.
MozReview-Commit-ID: FuLAwhmFTBe
Importantly, CreateResolvingFunctions, ResolvePromise, and TriggerPromiseReactions have been ported.
This reduces memory usage because before, the `resolve` and `reject` functions stored on a pending Promise kept track of each other and the Promise they belong to using a closure. Now, that state is stored in the functions' extended slots - which they have anyway.
It should also improve performance, as fewer switches between JS and C++ code occur during processing of Promise reaction job lists.
MozReview-Commit-ID: 9Wp0sDFayTy
Saves 96 bytes on reaction-less promises. It also saves 32 bytes on promises that have up to two reactions: empty arrays are initialized with an allocated length of 8, whereas providing an initial element initializes to 2.
MozReview-Commit-ID: 3PtT7LDwL3k
This saves a slot on Promise instances, an Array allocation, and a rejection record per dependent promise.
While the first doesn't in itself save anything (going from 12 to 11 slots doesn't do anything), the second saves 96 bytes per Promise, and the third 64 bytes per dependent Promise.
MozReview-Commit-ID: BglU9tx89rD
If we are inserting an XPCNativeSet into a NativeSetMap, and we failed
to find it, then the insertion should not have found some other set
there already.
Additionally in this case, the hash value of a XPCNativeSetKey for the
set we are inserting should be the same as the key we used to insert
the set into the map. If this property does not hold, then we can't
use Remove() to remove the set from the map. This condition would have
caught the error that part 1 fixes.
MozReview-Commit-ID: 23v37GzA4XV
--HG--
extra : rebase_source : 4dca7ffc436f53214eb2927bc1ff2f71927f7ac3
The current hash function fails to take into account that all
XPCNativeSets have nsISupports as their first element.
MozReview-Commit-ID: 7B8TPVnaM7I
--HG--
extra : rebase_source : a357f88a7d54aa1c9f58b6d429d4a5bbaaa13e80
We crash sometimes if we fail to add. We should always crash, because
we don't properly attempt to handle failure, and it would be nice to
get proper OOM-annotated crash reports.
MozReview-Commit-ID: EGgYxPdUSky
--HG--
extra : rebase_source : 92faf09c52452089b32cc430c04568b81e677f74
Some background first. For names that must be looked up dynamically, TDZ
checks are built in to the various NAME ops. For an assignment |x = 42|,
we emit:
BINDNAME "x"
INT8 42
SETNAME "x"
where the order of operations is:
1) BINDNAME first looks up the env where "x" is bound,
2) The RHS is evaluated,
3) The resulting value is assigned to "x" in the env from step 1)
That is, spec requires it that 3) is what throws any TDZ violations,
meaning we must evaluate RHS first. However, the implementation of
SETNAME is ultimately a call into SetProperty. Slowing down SetProperty
calls with TDZ checks was a non-starter. What we do instead is that if
BINDNAME sees a TDZ poison value when looking up the environment,
instead of pushing the actual environment, it pushes a magical
LexicalRuntimeErrorObject, which throws TDZ errors if it's touched in
any way (sets, gets, has-own-property, etc).
The code that created the LexicalRuntimeErrorObject did not understand
how to unwrap DebugScopeObjects, thus it considered that
DebugScopeObjects could never generate TDZ errors, leading to this bug.
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
--HG--
extra : rebase_source : e94323614bd10463a0c5134a7276238a7ca1cf23
Now we can see what is really happening in Hash: first hash the
interfaces from the base set, if any, then hash the additional
interface, if any.
Note that this function is wrong when mBaseSet is null. This will be
fixed in bug 1290239.
MozReview-Commit-ID: KaxQ57ofO1D
--HG--
extra : rebase_source : 42012878839adb2e36580480abce7d9708288db4
Both cases first hash together all of the existing interfaces.
MozReview-Commit-ID: AnUF5uPSPpN
--HG--
extra : rebase_source : 43ac016974d3ee4dfbd92361348aeeae5b6a793c
Now I take advantage of knowing that any new interface is always being
added to the end of the set.
Further cleanup of Hash() will happen in the next patch.
MozReview-Commit-ID: EoESTOfIOr
--HG--
extra : rebase_source : 8471391d23e3ff27a27156f55badbef3d1a4118b
There are three cases for a key, represented by the three ctors:
1. mBaseSet is non-null, mAddition is null.
2. mBaseSet is null, mAddition is non-null.
3. Both mBaseSet and mAddition are non-null.
In the three places that use the value of mPosition, condition 3
holds, so the key must have been constructed using the third ctor. For
this ctor, mPosition is equal to mBaseSet->GetInterfaceCount(), so I
substitute the value and eliminate the field.
This makes a check in NewInstanceMutate() trivially false, so I
eliminated that, too.
MozReview-Commit-ID: 1SOF6GyccU7
--HG--
extra : rebase_source : e215da19d77d6f88c216a48a07b9450c4d0e12bb
The mPosition field will be eliminated in a later patch.
MozReview-Commit-ID: EyVYZGgUWrH
--HG--
extra : rebase_source : 229ec989485bdd3ef86670a7c7db4149281a8d79
This explicitly represents the three types of keys that are used:
1. A key for an existing set.
2. A key for a new set with one interface added.
3. A key for an existing set with one new interface added at a
specified position.
MozReview-Commit-ID: Ctw41EymHbd
--HG--
extra : rebase_source : d7ce7d608a3d09df752313116c99bc2079d15a13
XPCNativeSet::GetNewOrUsed() and ::NewInstanceMutate() essentially
take XPCNativeSetKeys as arguments, but pass them around
unboxed. Passing around the keys explicitly will allow later changes
to enforce stronger invariants on keys.
MozReview-Commit-ID: CyQU3bUGinq
--HG--
extra : rebase_source : 5cdc651c1e4b9566dccd61b66de5e2bb8d6f33f5
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
This patch introduces a small change in behavior: we now unconditionally
require libffi > 3.0.9 when using system ffi, rather than accepting 3.0.9
when using GCC, as 3.0.10 was released 5 years ago, and should be widely
available.
MozReview-Commit-ID: DtSDPoZSPcx
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
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
This is to work around false GC hazards in ~XPCNativeInterface in part
4 of this bug. Putting RefPtr<XPCNativeInterface> on the stack means
that ~XPCNativeInterface can get called in various places, and the GC
hazard analysis does not understand the virtual methods involved, so
it assumes they might possibly GC.
This fixes one hazard by taking a jsid handle argument. The callers
already pass in handles, so no other changes are needed.
MozReview-Commit-ID: LpNpTlujpkm
This commit makes the following changes:
* Removed unnecessary includes of jslock.h from files that are using
js/src/thread/* primitives now.
* Removed includes of prcvar.h, prlock.h, and prthread.h in jslock.h.
* Renamed jslock.h to jsnspr.h since its only remaining utility is to either
wrap the few NSPR headers we still use, or alternatively include the
vm/PosixNSPR.h shim instead if JS_POSIX_NSPR is defined.
--HG--
rename : js/src/jslock.h => js/src/jsnspr.h
In JS StructuredClone BufferList<SystemAllocPolicy> is typedef'd to
JSStructuredCloneData and use everywhere in gecko that stores structured
clone data.
This patch changed some raw pointers to UniquePtr<JSStructuredCloneData>
and some to stack allocated JSStructuredCloneData for better life time
management. Some parameters or methods are deleted because of changing
to the new data structure.
MessagePortMessage now has the exactly same structure with
ClonedMessageData. Maybe in the future they can be consolidated.
MozReview-Commit-ID: 1IY9p5eKLgv
