Currently, some of the JS allocators accept an 'arena' argument, but some
don't. This change makes it so they all do. This is nice for consistency, but
it also feeds into Bug 1052579, which will need to use arenas for JSString
backing buffers.
Differential Revision: https://phabricator.services.mozilla.com/D19717
--HG--
extra : moz-landing-system : lando
I only converted a few low hanging fruits to the new API. Having to check for PrivateGCThing, which often can't even appear is a bit annoying, but I don't think we really need a different type.
I think next I can look into some of the extractNonDoubleType uses.
Differential Revision: https://phabricator.services.mozilla.com/D20474
--HG--
extra : moz-landing-system : lando
I only converted a few low hanging fruits to the new API. Having to check for PrivateGCThing, which often can't even appear is a bit annoying, but I don't think we really need a different type.
I think next I can look into some of the extractNonDoubleType uses.
Differential Revision: https://phabricator.services.mozilla.com/D20474
--HG--
extra : moz-landing-system : lando
r?njn only because this is the first example that adds any actual subcategories.
Differential Revision: https://phabricator.services.mozilla.com/D11340
--HG--
extra : moz-landing-system : lando
This is similar to AUTO_PROFILER_LABEL, but with only one argument: a category pair.
This reduces duplication for label frames that want just the subcategory name as
their label: Instead of AUTO_PROFILER_LABEL("Layer building", GRAPHICS_LayerBuilding),
you can now just write AUTO_PROFILER_LABEL_CATEGORY_PAIR(GRAPHICS_LayerBuilding) and
the string will automatically be taken from the subcategory.
Differential Revision: https://phabricator.services.mozilla.com/D11339
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--HG--
extra : moz-landing-system : lando
Define a new RAII class, AutoDebuggerJobQueueInterruption, to save and restore
the current ECMAScript job queue, to protect the debuggee's job queue from
activity that occurs in debugger callbacks. Add a new method to the JS::JobQueue
abstract base class, saveJobQueue, to support AutoDebuggerJobQueueInterruption.
Comments on AutoDebuggerJobQueueInterruption provide details.
Implement saveJobQueue for SpiderMonkey's internal job queue and for Gecko's job
queue in CycleCollectedJSContext.
Differential Revision: https://phabricator.services.mozilla.com/D17546
--HG--
extra : moz-landing-system : lando
While the behavior of ECMAScript Promises and their associated job queue is
covered by the ECMAScript standard, the HTML specification amends that with
additional behavior the web platform requires. To support this, SpiderMonkey
provides hooks the embedding can set to replace SpiderMonkey's queue with its
own implementation.
At present, these hooks are C-style function-pointer-and-void-pointer pairs,
which are awkward to handle and mistake-prone, as passing a function the wrong
void* is not a type error. Later patches in this series must add new hooks,
making a bad situation worse.
A C++ abstract base class is a well-typed alternative. This introduces a new
`JS::JobQueue` abstract class, and adapts SpiderMonkey's internal job queue and
Gecko's customization to use it. `GetIncumbentGlobalCallback` and
`EnqueuePromiseJobCallback` become virtual methods.
Within SpiderMonkey, the patch gathers the various fields of JSContext that
implement the internal queue into their own type, js::InternalJobQueue. Various
jsfriendapi functions become veneers for calls to methods specific to the
derived class. The InternalJobQueue type itself remains private to SpiderMonkey,
as it uses types like TraceableFifo, derived from Fifo, that are not part of
SpiderMonkey's public API.
Within Gecko, CycleCollectedJSContext acquires JS::JobQueue as a private base
class, and a few static methods are cleaned up nicely.
There are a few other hooks defined in js/public/Promise.h that might make sense
to turn into virtual methods on JobQueue. For example,
DispatchToEventLoopCallback, used for resolving promises of results from
off-main-thread tasks, is probably necessarily connected to the JobQueue
implementation in use, so it might not be sensible to set one without the other.
But it was left unchanged to reduce this patch's size.
Differential Revision: https://phabricator.services.mozilla.com/D17544
--HG--
extra : moz-landing-system : lando
In vm/Iteration.cpp this inlines some functions because there's a single
caller now. Follow-up patches will do additional cleanup/optimization.
Differential Revision: https://phabricator.services.mozilla.com/D18926
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
We're going to need this because we will have multiple Realms in the same
compartment which want different CheckedUnwrap behavior in some cases. So we
need to be able to check which Realm we're in.
Differential Revision: https://phabricator.services.mozilla.com/D17881
--HG--
extra : moz-landing-system : lando
I am bit surprised myself, but just removing the getPropertyDescriptor trap seems to mostly work.
The only real special case here is the XPC Sandbox, which I changed to keep using its getPropertyDescriptorImpl.
testSetPropertyIgnoringNamedGetter.cpp didn't even really need its getPropertyDescriptor implementation.
Differential Revision: https://phabricator.services.mozilla.com/D17386
--HG--
extra : moz-landing-system : lando
