* GetScriptCompartment => GetScriptRealm
* Adds IsSystemRealm in addition to IsSystemCompartment and uses it where we can.
* JS_GetCompartmentPrincipals and IsSystemCompartment now release-assert they have a single realm. This is temporary until we know what Gecko will do/need exactly.
At some point I'll audit the obj->realm() calls for CCWs; removing RealmBehaviorsRef(obj) prepares for that.
Also, RealmBehaviorsRef(realm) could be removed and we could use RealmBehaviorsRef(cx) everywhere, but it seems reasonable to keep it.
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Some of the less trivial changes:
* When we allocated a symbol, we used the atom realm's RNG to create a hash code [0]. Instead of this I added a RNG for this to the runtime.
* IsCompilingWasm returned true if the JitContext's realm is nullptr, but that's now also true when we initialize the trampolines stored in the atoms zone. To fix that I added a CompileZone* to JitContext, in addition to the CompileRuntime and CompileRealm, and we now check the zone instead of the realm in IsCompilingWasm.
* JSContext::hasEnteredRealm is only called in DEBUG builds so I made hasEnteredRealm and enterRealmDepth_ #ifdef DEBUG.
Tracing the script members held alive by PrecompiledScript objects can be
expensive, especially for large scripts. It would be nice if we could avoid
tracing them when possible.
Most of the time, when PrecompiledScripts are alive, they're held alive by
black roots, and have black JS wrappers. In those cases, there's no chance of
them creating garbage cycles, and we can just mark their script children
black.
MozReview-Commit-ID: KnkJfznJZBx
--HG--
extra : rebase_source : da0da30265c3f752c9aba177bf510937a743e49e
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 344c380ddaaf42a1fd820a26b762c61ee9e2d524
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : f807c14bf6a592e0c651e15b63d1e7d63e4b0159
Any more specific work that is happening in these methods will have its own
specific category labeling in that specific code. The instances touched in this
patch are more on the outside and don't really know what kind of code is going
to be running inside.
MozReview-Commit-ID: 47NO1DZzkdH
--HG--
extra : rebase_source : 35362bc94068103367f46b23a14cb3831cd86990
The ScriptPreloader stopped recording before browser-delayed-startup-finished before, but there
are other scripts (both in the parent and content processes) that might run soon after that we
also want to cache. This increases the probability that those scripts are noted by the
ScriptPreloader cache.
MozReview-Commit-ID: KiBEVvuqQkA
--HG--
extra : rebase_source : 4c1bffa882b0641f93260867ac8a4334b1269e99
This implements a new kind of lazy getter in XPCOMUtils that creates an object (implemented as a JS Proxy) that is resilient to be passed around as references to other functions, and will only evaluate the getter when it really needs to be used
