In D25705, I added a new arenaId member to the js::BaseAllocPolicy. This
increased the size of everything that uses a JS AllocPolicy, which is a
lot.
This change follows suit from earlier work, which is to make everything
allocation-related have an "arena" version and a "default" version that
uses the arena version with the implied default arena.
StringBuffer is then changed to use this new functionity to define its
own alloc policy that uses the new StringBufferArena.
Differential Revision: https://phabricator.services.mozilla.com/D29685
--HG--
extra : moz-landing-system : lando
Added 'RunnableTask' struct to Utility.h to unify HelperThread task types in a way that can be exposed to XPCOM thread pools. Re-implemented tasks within native HelperThreads using their runnableTask method.
Differential Revision: https://phabricator.services.mozilla.com/D24921
--HG--
extra : moz-landing-system : lando
Currently, JSAPI malloc calls can only allocate in MallocArena. Now there
are calls for when the user intends to allocate a buffer that will be
"stolen" by one of the NewString calls.
Differential Revision: https://phabricator.services.mozilla.com/D25709
--HG--
extra : moz-landing-system : lando
This patch enables compilation of the tracelogger by default on nightly builds
as well as providing an environment variable (JS_TRACE_LOGGING) to enable or
disable tracelogger instrumentation when compiling Javascript. This helps to
reduce the performance impact of the Tracelogger code when not in use. In the
future, this could be improved to recompile the JS with/without Tracelogger
instrumentation when toggling Tracelogger support.
Differential Revision: https://phabricator.services.mozilla.com/D26255
--HG--
extra : moz-landing-system : lando
Several of these JS char-copying functions allocate memory, and currently
they implicitly do it in the MallocArena. They now take an explicit argument
about which arena they perform their allocation in.
Differential Revision: https://phabricator.services.mozilla.com/D25708
--HG--
extra : moz-landing-system : lando
This way it's easier and faster to access from JIT code.
The old code in GlobalObject::offsetOfLexicalEnvironmentSlot was wrong because
it didn't account for the global having a private slot (XPConnect globals).
Differential Revision: https://phabricator.services.mozilla.com/D26083
--HG--
extra : moz-landing-system : lando
Several areas of JS code abstract their memory allocation logic behind an
AllocPolicy. Since these allocations may now need to be in different arenas,
each AllocPolicy will need to be assigned a Mozjemalloc arena that it will
use for all its allocations.
Differential Revision: https://phabricator.services.mozilla.com/D25705
--HG--
extra : moz-landing-system : lando
Mechanical change from Matcher::match(...) to Matcher::operator()(...).
This will now permit the use of generic lambdas, and facilitate the
implementation of multi-lambda match.
Differential Revision: https://phabricator.services.mozilla.com/D24889
--HG--
extra : moz-landing-system : lando
This adds a pre write barrier to Heap<T> so that these can be uses as non-roots in the heap without breaking our snapshot at the beginning invariant if they are written to during an incremental GC. This makes it harder to misuse and allows us to take out manual barriers in at least one place.
Differential Revision: https://phabricator.services.mozilla.com/D25083
Introduce a MOZ_STACK_CLASS StackGCVector, which is
specialization of inline capacity to 8 of GCVector.
Differential Revision: https://phabricator.services.mozilla.com/D23182
--HG--
extra : moz-landing-system : lando
Since this mode covers both incremental and zonal GC, let's rename it to
reflect that. JSGC_MODE_ZONE_INCREMENTAL.
Differential Revision: https://phabricator.services.mozilla.com/D24849
--HG--
extra : moz-landing-system : lando
This creates a shell command-line option, `--enable-experimental-fields`, and a
Gecko pref, `javascript.options.experimental.fields`.
Both are off by default everywhere, for now.
Differential Revision: https://phabricator.services.mozilla.com/D22045
--HG--
extra : moz-landing-system : lando
This creates a shell command-line option, `--enable-experimental-fields`, and a
Gecko pref, `javascript.options.experimental.fields`.
Both are off by default everywhere, for now.
Differential Revision: https://phabricator.services.mozilla.com/D22045
--HG--
extra : moz-landing-system : lando
This adds the basic infrastructure and uses it for some Math natives and the
Array constructor.
Differential Revision: https://phabricator.services.mozilla.com/D20340
--HG--
extra : moz-landing-system : lando
The CacheIR code only sees transparent CCWs so it's fine to do a static unwrap.
DebuggerObject::unwrap is more complicated. We're in the debugger's compartment
there; I went with UnwrapOneCheckedStatic as it seems safest and simplest for
now.
Differential Revision: https://phabricator.services.mozilla.com/D21354
--HG--
extra : moz-landing-system : lando
Remove the `if (!mozilla::IsPointer<T>::value || thing)` check in
GCVariantImplementation::trace, as GCPolicy will dispatch these to
GCPointerPolicy and InternalPointerPolicy (for pointers) and StructGCPolicy (for
non-pointers).
Also use Rooted for prevState_ in AutoSetNewObjectMetadata and remove
inherit from CustomAutoRooter.
We collect the nursery in idle time if there is less than 256KB of space
remaining. However when the nursery is small this doesn't make sense, so
add a percentage-based threshold to be used when the nursery is small.
Differential Revision: https://phabricator.services.mozilla.com/D20247
--HG--
extra : moz-landing-system : lando
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
