Debugger invisibility is only practical to enforce on compartment boundaries,
and for its proper uses, that's good enough. Unfortunately, at present, debugger
invisibility is a flag on realms. This misfit is the reason for the sole
remaining code that assumes that every object is associated with a particular
realm: Debugger.Object.prototype.unwrap consults the unwrapped object's global
to see whether it is about to reveal an object that it must not. We would like
to remove this code.
This patch:
- adds an `invisibleToDebugger` flag to JS::Compartment, and sets it from the
Realm options (since there is no API for creating compartments directly; only
the act of creating a Realm can create a compartment to hold it);
- changes Debugger.Object.prototype.unwrap to check the compartment's flag, thus
removing the final use of JSObject::deprecatedRealm;
- asserts that new realms added to a compartment have a compatible visibility; and
- changes the shell primitive for creating realms to throw an error in case of
incompatible requested visibilities, rather than crashing.
Differential Revision: https://phabricator.services.mozilla.com/D14625
--HG--
extra : moz-landing-system : lando
Currently createStackMap makes a temporary clone of StackMapGenerator::mst_ on
every call. This will cause a heap allocation and free in the case where
mst_'s vector size exceeds its inline capacity (64 booleans). This patch
removes the cloning and instead adds a second MachineStackTracker,
augmentedMst_, to StackMapGenerator, which is used as the temporary inside
createStackMap. The expectation is that augmentedMst_'s vector will grow in
capacity monotonically during the lifetime of the StackMapGenerator, that is,
over multiple calls to createStackMap. This should significantly cut down on
heap (re)allocation caused by createStackMap.
--HG--
extra : rebase_source : 3a682e88571c1452f15efe711be3e403f64e0a8f
Because it release-asserts the compartment has a single realm.
I also renamed JS_GetCompartmentPrincipals to JS_DeprecatedGetCompartmentPrincipals
to discourage people from using it.
Differential Revision: https://phabricator.services.mozilla.com/D14252
--HG--
extra : moz-landing-system : lando
We were failing the realm assert in UnboxedLayout::makeNativeGroup in the browser.
It's possible the assert is overzealous and we don't need the AutoRealm, but this
makes it much easier to reason about the code.
Differential Revision: https://phabricator.services.mozilla.com/D14693
--HG--
extra : moz-landing-system : lando
This fixes bug 1406437. It also simplifies JSScript because it now always stores
a ScriptSourceObject directly instead of a CCW for one.
Differential Revision: https://phabricator.services.mozilla.com/D13974
--HG--
extra : moz-landing-system : lando
But keep the crashreporter disabled at runtime because it doesn't work
yet.
This has the side effect of creating the artifacts with the
crashreporter symbols and pdbs.
Differential Revision: https://phabricator.services.mozilla.com/D14550
--HG--
extra : moz-landing-system : lando
CCWs are not really associated with a single realm and we assert code doesn't
enter/request the realm or global of a CCW. However they currently still have an
ObjectGroup that's associated with a single realm. Using the same realm avoids
some potential memory usage issues.
Differential Revision: https://phabricator.services.mozilla.com/D14531
--HG--
extra : moz-landing-system : lando
In js.cpp, BindToAsyncStack used JSObject::isCallable to check the type of its
argument, and then BoundToAsyncStack (the native for the function returned)
assumed that it could call JSObject::as<JSFunction> on that value.
However, there are many things that are isCallable but not is<JSFunction>, two
examples being CCWs and function proxies.
Differential Revision: https://phabricator.services.mozilla.com/D14343
--HG--
extra : moz-landing-system : lando
