This should specifically prevent bug 1553938 from happening in the
future. Unfortunately it won't prevent other similar bugs from
happening.
Differential Revision: https://phabricator.services.mozilla.com/D52463
--HG--
extra : moz-landing-system : lando
Whether ENABLE_INTL_API and ENABLE_TYPED_OBJECTS are defined, affects
the behaviour of JS_FOR_PROTOTYPES for the prototypes of Intl and
TypedObject. Therefore, these macros have to be available to embedders.
Rename them to JS_HAS_INTL_API and JS_HAS_TYPED_OBJECTS (in line with
the existing JS_HAS_CTYPES) everywhere they are used, and add them to
js-config.h.in.
Differential Revision: https://phabricator.services.mozilla.com/D52461
--HG--
extra : moz-landing-system : lando
Previously, if SpiderMonkey embedders linked to a copy of libmozjs built
with --enable-cranelift, --enable-wasm-gc, or --enable-fuzzing, then the
size of the ContextOptions data structure declared in the header file
would be different than the size of ContextOptions in the library,
likely leading to crashes. This makes all members of ContextOptions
independent of preprocessor macros. Any options not compiled into
SpiderMonkey will still be no-ops.
Differential Revision: https://phabricator.services.mozilla.com/D52460
--HG--
extra : moz-landing-system : lando
We should have the same public API available whenever possible, and make
it a no-op or make it throw immediately if JS was built without support
for it, instead of showing or hiding the API in header files using
configure macros. Otherwise embedders can easily get mismatches between
a library with functionality and header files without it, or vice versa.
There was no good reason why JS_GetErrorType() was nightly-only API, so
this also enables it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D52124
--HG--
extra : moz-landing-system : lando
This should specifically prevent bug 1553938 from happening in the
future. Unfortunately it won't prevent other similar bugs from
happening.
Differential Revision: https://phabricator.services.mozilla.com/D52463
--HG--
extra : moz-landing-system : lando
Whether ENABLE_INTL_API and ENABLE_TYPED_OBJECTS are defined, affects
the behaviour of JS_FOR_PROTOTYPES for the prototypes of Intl and
TypedObject. Therefore, these macros have to be available to embedders.
Rename them to JS_HAS_INTL_API and JS_HAS_TYPED_OBJECTS (in line with
the existing JS_HAS_CTYPES) everywhere they are used, and add them to
js-config.h.in.
Differential Revision: https://phabricator.services.mozilla.com/D52461
--HG--
extra : moz-landing-system : lando
Previously, if SpiderMonkey embedders linked to a copy of libmozjs built
with --enable-cranelift, --enable-wasm-gc, or --enable-fuzzing, then the
size of the ContextOptions data structure declared in the header file
would be different than the size of ContextOptions in the library,
likely leading to crashes. This makes all members of ContextOptions
independent of preprocessor macros. Any options not compiled into
SpiderMonkey will still be no-ops.
Differential Revision: https://phabricator.services.mozilla.com/D52460
--HG--
extra : moz-landing-system : lando
We should have the same public API available whenever possible, and make
it a no-op or make it throw immediately if JS was built without support
for it, instead of showing or hiding the API in header files using
configure macros. Otherwise embedders can easily get mismatches between
a library with functionality and header files without it, or vice versa.
There was no good reason why JS_GetErrorType() was nightly-only API, so
this also enables it unconditionally.
Differential Revision: https://phabricator.services.mozilla.com/D52124
--HG--
extra : moz-landing-system : lando
Adds AggregateError, but only enables it for Nightly builds, because the draft
proposal is still incomplete, so it doesn't make sense to let this feature ride
the trains at this moment.
- The `other_error_properties` array was changed to individual static variables,
because AggregateError has more than three properties, which prevents it to be
stored in `JSPropertySpec[][3]`.
- `AggregateErrorObject` can't use the normal `ErrorObject` class, because it
needs an additional slot for the [[AggregateErrors]].
- For similar reasons it can't use the shared `Error` constructor function,
because the `AggregateError` constructor has an additional `errors` iterable
argument which it needs to process.
Differential Revision: https://phabricator.services.mozilla.com/D51653
--HG--
extra : moz-landing-system : lando
I don't know why these methods return a boolean, but I can't find any uses of it so I removed it.
Differential Revision: https://phabricator.services.mozilla.com/D53694
--HG--
extra : moz-landing-system : lando
All JSProtoKey entries are now using `InitViaClassSpec`, so we can remove the 'init'
parameter from `JS_FOR_PROTOTYPES` and update all callers accordingly. Furthermore
the `protoTable` array can be changed to an array of `JSClass*` and
`GlobalObject::resolveConstructor` can be cleaned-up to always use the ClassSpec
initialisation path.
Differential Revision: https://phabricator.services.mozilla.com/D52706
--HG--
extra : moz-landing-system : lando
Also use ClassSpec initialisation for all WebAssembly namespace constructors
to ensure a failed initialisation can still be retried.
Differential Revision: https://phabricator.services.mozilla.com/D52705
--HG--
extra : moz-landing-system : lando
The "constructor" property of the GeneratorFunction prototype is non-writable,
so we need to manually adjust the property attributes in the `FinishClassInitOp`.
This change needs to happen first to ensure "constructor" is still stored in
the last property, which in turn ensures the property can be modified without
triggering a transition into dictionary mode.
jsapi.cpp:
Remove the JSProto_GeneratorFunction special cases now that we can use
`ClassSpec::DontDefineConstructor`.
Differential Revision: https://phabricator.services.mozilla.com/D52677
--HG--
extra : moz-landing-system : lando
Proxy JSClasses are defined through a special macro (`PROXY_CLASS_DEF`), which
ensures all Proxy related bits are set correctly. The macro doesn't allow to
specify a ClassSpec, so we need to add a new macro which supports that
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D52666
--HG--
extra : moz-landing-system : lando
Similar to the JSON changes in part 5. Additionally 'FinishClassInitOp' is
needed to initialise the double constant properties.
Differential Revision: https://phabricator.services.mozilla.com/D52662
--HG--
extra : moz-landing-system : lando
The JSON ClassSpec uses a custom 'createConstructor', because the JSON object
is a singleton object and not a built-in constructor function.
Differential Revision: https://phabricator.services.mozilla.com/D52661
--HG--
extra : moz-landing-system : lando
A ClassSpec's 'FinishClassInitOp' isn't called when `InitBareBuiltinCtor` is
used, which allows us to unconditionally define all well-known symbols in
`SymbolClassFinish`. That means we no longer need the separate `InitBareSymbolCtor`
function.
Differential Revision: https://phabricator.services.mozilla.com/D52660
--HG--
extra : moz-landing-system : lando
Move String to ClassSpec using similar changes like done for Number in part 2.
Differential Revision: https://phabricator.services.mozilla.com/D52659
--HG--
extra : moz-landing-system : lando
In addition to a custom 'createProperty' hook, the Number ClassSpec also uses
a 'FinishClassInitOp' to initialise Number-related global properties like
`isNaN` and to initialise functions which are shared between Number and the
global object (i.e. `parseInt`).
Differential Revision: https://phabricator.services.mozilla.com/D52658
--HG--
extra : moz-landing-system : lando
Boolean.prototype is itself a Boolean object, so the ClassSpec needs to use
a custom 'createPrototype' function to create and initialise the prototype
object.
Differential Revision: https://phabricator.services.mozilla.com/D52657
--HG--
extra : moz-landing-system : lando
All JSProtoKey entries are now using `InitViaClassSpec`, so we can remove the 'init'
parameter from `JS_FOR_PROTOTYPES` and update all callers accordingly. Furthermore
the `protoTable` array can be changed to an array of `JSClass*` and
`GlobalObject::resolveConstructor` can be cleaned-up to always use the ClassSpec
initialisation path.
Differential Revision: https://phabricator.services.mozilla.com/D52706
--HG--
extra : moz-landing-system : lando
Also use ClassSpec initialisation for all WebAssembly namespace constructors
to ensure a failed initialisation can still be retried.
Differential Revision: https://phabricator.services.mozilla.com/D52705
--HG--
extra : moz-landing-system : lando
The "constructor" property of the GeneratorFunction prototype is non-writable,
so we need to manually adjust the property attributes in the `FinishClassInitOp`.
This change needs to happen first to ensure "constructor" is still stored in
the last property, which in turn ensures the property can be modified without
triggering a transition into dictionary mode.
jsapi.cpp:
Remove the JSProto_GeneratorFunction special cases now that we can use
`ClassSpec::DontDefineConstructor`.
Differential Revision: https://phabricator.services.mozilla.com/D52677
--HG--
extra : moz-landing-system : lando
Proxy JSClasses are defined through a special macro (`PROXY_CLASS_DEF`), which
ensures all Proxy related bits are set correctly. The macro doesn't allow to
specify a ClassSpec, so we need to add a new macro which supports that
functionality.
Differential Revision: https://phabricator.services.mozilla.com/D52666
--HG--
extra : moz-landing-system : lando
Similar to the JSON changes in part 5. Additionally 'FinishClassInitOp' is
needed to initialise the double constant properties.
Differential Revision: https://phabricator.services.mozilla.com/D52662
--HG--
extra : moz-landing-system : lando
The JSON ClassSpec uses a custom 'createConstructor', because the JSON object
is a singleton object and not a built-in constructor function.
Differential Revision: https://phabricator.services.mozilla.com/D52661
--HG--
extra : moz-landing-system : lando
A ClassSpec's 'FinishClassInitOp' isn't called when `InitBareBuiltinCtor` is
used, which allows us to unconditionally define all well-known symbols in
`SymbolClassFinish`. That means we no longer need the separate `InitBareSymbolCtor`
function.
Differential Revision: https://phabricator.services.mozilla.com/D52660
--HG--
extra : moz-landing-system : lando
Move String to ClassSpec using similar changes like done for Number in part 2.
Differential Revision: https://phabricator.services.mozilla.com/D52659
--HG--
extra : moz-landing-system : lando
In addition to a custom 'createProperty' hook, the Number ClassSpec also uses
a 'FinishClassInitOp' to initialise Number-related global properties like
`isNaN` and to initialise functions which are shared between Number and the
global object (i.e. `parseInt`).
Differential Revision: https://phabricator.services.mozilla.com/D52658
--HG--
extra : moz-landing-system : lando
Boolean.prototype is itself a Boolean object, so the ClassSpec needs to use
a custom 'createPrototype' function to create and initialise the prototype
object.
Differential Revision: https://phabricator.services.mozilla.com/D52657
--HG--
extra : moz-landing-system : lando
Adds AggregateError, but only enables it for Nightly builds, because the draft
proposal is still incomplete, so it doesn't make sense to let this feature ride
the trains at this moment.
- The `other_error_properties` array was changed to individual static variables,
because AggregateError has more than three properties, which prevents it to be
stored in `JSPropertySpec[][3]`.
- `AggregateErrorObject` can't use the normal `ErrorObject` class, because it
needs an additional slot for the [[AggregateErrors]].
- For similar reasons it can't use the shared `Error` constructor function,
because the `AggregateError` constructor has an additional `errors` iterable
argument which it needs to process.
Differential Revision: https://phabricator.services.mozilla.com/D51653
--HG--
extra : moz-landing-system : lando
This matches the JitCode GC-thing lifetime and will hopefully help avoid
fragmentation.
Differential Revision: https://phabricator.services.mozilla.com/D52823
--HG--
extra : moz-landing-system : lando
This adds two AUTO_PROFILER_LABEL_DYNAMIC_... macros and updates select
usages of the old macros to use the new ones. These new macros cause
the dynamic string of the label to be included in BHR stacks.
We don't want to do this all of the time, as in many cases we may not
be interested enough in the dynamic string or it may be sensitive
information, but it is rather important information for certain cases.
This uses the same buffer that we use for the strings for JS frames,
and if we fail to fit into that buffer we just append the raw label.
If the string is too long for our static buffer (128 bytes), we just
leave it truncated, as it should be stable and we may be able to infer
from the truncated form what the full form would be.
Differential Revision: https://phabricator.services.mozilla.com/D51665
--HG--
extra : moz-landing-system : lando
This macro isn't defined anywhere and doesn't seem to do anything. It
affects the oom-backtraces property of the build configuration object in
the testing functions, but since the macro is never defined, it seems to
be always set to false anyway, so just hardcode it.
Differential Revision: https://phabricator.services.mozilla.com/D51769
--HG--
extra : moz-landing-system : lando
This macro is not defined anywhere and has no effect in the end whether
it's defined or not.
Differential Revision: https://phabricator.services.mozilla.com/D51767
--HG--
extra : moz-landing-system : lando
This file provides the implementation of js/Utility.h, so it should be renamed
to match the header name.
Differential Revision: https://phabricator.services.mozilla.com/D51378
--HG--
rename : js/src/jsutil.cpp => js/src/util/Utility.cpp
extra : moz-landing-system : lando
JS_BIT and JS_BITMASK are only used in contexts where uint32_t is used, so these
two functions are now typed to accept and return uint32_t.
JS_HOWMANY and the three JS_ROUND functions are only used with size_t inputs,
so these four functions are now typed to accept and return size_t.
Differential Revision: https://phabricator.services.mozilla.com/D51142
--HG--
extra : moz-landing-system : lando
This macro makes any forward declarations unnecessarily verbose, and the
build system uses Clang by default anyway, except in the hazard analysis
which already specified -Wno-attributes.
Depends on D49097
Differential Revision: https://phabricator.services.mozilla.com/D49098
--HG--
extra : moz-landing-system : lando
This replaces a direct call of an object's finalizer with a more formal API. This adds some assertions and passes a valid FreeOp pointer to the finalizer rather than null.
Differential Revision: https://phabricator.services.mozilla.com/D50571
--HG--
extra : moz-landing-system : lando
This makes JS::AddAssociatedMemory() and JS::RemoveAssociatedMemory()
more useful for embedders.
Differential Revision: https://phabricator.services.mozilla.com/D50347
--HG--
extra : moz-landing-system : lando
This renames the JSStringFinalizer struct to JSExternalStringCallbacks,
makes it a virtual class, and adds a size-of callback to it (to replace
the per-runtime callback).
This will make it possible to implement this callback easily for the
NewExternalString testing function (which we want for bug 1590641)
without having to move this testing function to shell/js.cpp
Differential Revision: https://phabricator.services.mozilla.com/D50234
--HG--
extra : moz-landing-system : lando
We can simplify this method by using std::remove_if, which does the shifting down of removed elements for us. We just need to make sure all our wrapper classes support moving assignment.
Differential Revision: https://phabricator.services.mozilla.com/D49769
--HG--
extra : moz-landing-system : lando
The DebuggerVector has been associated with the GlobalObject via a private slot
referencing a wrapper JS object (DebugggerVectorHolder). Moving this data into
the JS::Realm instance removes complexity and avoids needing the holder.
Differential Revision: https://phabricator.services.mozilla.com/D49570
--HG--
extra : moz-landing-system : lando
"disjunction" and "unit" types aren't yet supported, because ICU doesn't
provide a C-API for this functionality. "short" and "narrow" styles aren't
supported for the same reason.
Differential Revision: https://phabricator.services.mozilla.com/D40437
--HG--
extra : moz-landing-system : lando
In a follow-up bug this will be changed to use `ClassSpec`, along with the rest
of the JSProtoKey classes still using non-ClassSpec initialisation.
Differential Revision: https://phabricator.services.mozilla.com/D42883
--HG--
extra : moz-landing-system : lando
Increase the CACHED_PROTO_KEY limit from 2⁶ to 2⁷ to allow that all current
JSProto classes can use JSCLASS_HAS_CACHED_PROTO.
Differential Revision: https://phabricator.services.mozilla.com/D42878
--HG--
extra : moz-landing-system : lando
- `JSProto_Collator` has to be added to the end until part 9.
- `js::CreateCollatorPrototype` was renamed to `js::CreateCollator` because it
no longer returns the prototype object. Part 7 will change this again.
- `CollatorObject::protoClass_` uses `PlainObject::class_`, which works because
CollatorObject isn't xrayable.
Differential Revision: https://phabricator.services.mozilla.com/D42870
--HG--
extra : moz-landing-system : lando
In a follow-up bug this will be changed to use `ClassSpec`, along with the rest
of the JSProtoKey classes still using non-ClassSpec initialisation.
Differential Revision: https://phabricator.services.mozilla.com/D42883
--HG--
extra : moz-landing-system : lando
Increase the CACHED_PROTO_KEY limit from 2⁶ to 2⁷ to allow that all current
JSProto classes can use JSCLASS_HAS_CACHED_PROTO.
Differential Revision: https://phabricator.services.mozilla.com/D42878
--HG--
extra : moz-landing-system : lando
- `JSProto_Collator` has to be added to the end until part 9.
- `js::CreateCollatorPrototype` was renamed to `js::CreateCollator` because it
no longer returns the prototype object. Part 7 will change this again.
- `CollatorObject::protoClass_` uses `PlainObject::class_`, which works because
CollatorObject isn't xrayable.
Differential Revision: https://phabricator.services.mozilla.com/D42870
--HG--
extra : moz-landing-system : lando
jspubtd.h is for type definitions so this moves the heap state functions to somewhere more suitable.
Depends on D49116
Differential Revision: https://phabricator.services.mozilla.com/D49117
--HG--
extra : moz-landing-system : lando
We want to remove flat strings (JSFlatString). With this patch we only expose
linear strings (JSLinearString) to API consumers.
This is very mechanical for the most part, because code typically only cares
about linear strings and not the null-termination aspect.
CTypes's Library.cpp has some Windows-specific code where we relied on null-terminated
strings. This patch adds JS_CopyStringCharsZ for that use case.
Differential Revision: https://phabricator.services.mozilla.com/D48314
--HG--
extra : moz-landing-system : lando
The root marking functions have assertions that will catch this being used outside of heap marking.
Differential Revision: https://phabricator.services.mozilla.com/D48534
--HG--
extra : moz-landing-system : lando
GCPolicy<T> calls the instance method for these types so these static methods aren't required.
Differential Revision: https://phabricator.services.mozilla.com/D48533
--HG--
extra : moz-landing-system : lando
Finally, here we add the virtual method isSystemOrAddonPrincipal to the
JSPrincipal object.
We also add it to nsJSPrincipal (where it has an easy implementation), and
to carry classes that are used by JS tests and the shell.
Differential Revision: https://phabricator.services.mozilla.com/D47477
--HG--
extra : moz-landing-system : lando
In a future commit we will tie this boolean to its own preference value, but here we
initialize it with the same value as the wasm boolean.
We also update wasm::HasSupport to check the to-be-added isSystemOrAddonPrincipal()
method on JSPrincipals to determine which member (wasm or wasmForTrustedPrinciples)
to consult.
Differential Revision: https://phabricator.services.mozilla.com/D47472
--HG--
extra : moz-landing-system : lando
CreationOptions are intended to be immutable and not change during realm operation.
Behaviors change, and clamping/jittering should reside on behaviors.
Differential Revision: https://phabricator.services.mozilla.com/D43296
--HG--
extra : moz-landing-system : lando
Also:
* Update the DefaultNurseryMaxBytes comment
* Fix the shell parameter handling.
Differential Revision: https://phabricator.services.mozilla.com/D47869
--HG--
extra : moz-landing-system : lando
Also:
* Update the DefaultNurseryMaxBytes comment
* Fix the shell parameter handling.
Differential Revision: https://phabricator.services.mozilla.com/D47869
--HG--
extra : moz-landing-system : lando
Abstracts the pointer unboxing pattern for both NUNBOX32 and PUNBOX64
formats. This also encapsulates some of the spectre mitigations.
Differential Revision: https://phabricator.services.mozilla.com/D46326
--HG--
extra : moz-landing-system : lando
Now that all the bad type-punning is gone, JS::Value has a single
asBits_ field and we should use a class aggregate type instead.
Differential Revision: https://phabricator.services.mozilla.com/D46325
--HG--
extra : moz-landing-system : lando
Use well-defined conversions on the asBits_ instead. This removes union
arms entirely. They are slighly useful for debugging, but we don't have
that on our 64-bit platforms and the gdb helpers can already help us
out.
Differential Revision: https://phabricator.services.mozilla.com/D46324
--HG--
extra : moz-landing-system : lando
Use well-defined conversions on the asBits_ instead. The remaining union
arms were not even helpful for debuggers so we remove entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46323
--HG--
extra : moz-landing-system : lando
This is a process-wide callback that can be used by embedders to block parsing
or decoding of scripts that are considered unsafe.
Differential Revision: https://phabricator.services.mozilla.com/D44620
--HG--
extra : moz-landing-system : lando
Abstracts the pointer unboxing pattern for both NUNBOX32 and PUNBOX64
formats. This also encapsulates some of the spectre mitigations.
Differential Revision: https://phabricator.services.mozilla.com/D46326
--HG--
extra : moz-landing-system : lando
Now that all the bad type-punning is gone, JS::Value has a single
asBits_ field and we should use a class aggregate type instead.
Differential Revision: https://phabricator.services.mozilla.com/D46325
--HG--
extra : moz-landing-system : lando
Use well-defined conversions on the asBits_ instead. This removes union
arms entirely. They are slighly useful for debugging, but we don't have
that on our 64-bit platforms and the gdb helpers can already help us
out.
Differential Revision: https://phabricator.services.mozilla.com/D46324
--HG--
extra : moz-landing-system : lando
Use well-defined conversions on the asBits_ instead. The remaining union
arms were not even helpful for debuggers so we remove entirely.
Differential Revision: https://phabricator.services.mozilla.com/D46323
--HG--
extra : moz-landing-system : lando
If either the Realm or the request needs full-parsing, we disable lazy
parsing.
Differential Revision: https://phabricator.services.mozilla.com/D42560
--HG--
extra : moz-landing-system : lando
We already have an accessor to make sure this is can only be set but not
cleared so hide the underlying storage.
Differential Revision: https://phabricator.services.mozilla.com/D42559
--HG--
extra : moz-landing-system : lando
Also closes bug 1576216: update ZoneStats and RealmStats memory
accounting for this change.
Differential Revision: https://phabricator.services.mozilla.com/D42977
--HG--
extra : moz-landing-system : lando
This renames:
HeapSize::gcBytes -> bytes (it's not just for GC heaps any more)
ZoneThreshold -> HeapThreshold (to go with HeapSize)
HeapThreshold::triggerBytes -> bytes (what else could it be?)
I renamed the ZoneAllocator members to make them more uniform/consitent so we now have gcHeapSize/gcHeapThreshold, mallocHeapSize/mallocHeapThreshold etc.
I also renamed the heap threshold classes.
Differential Revision: https://phabricator.services.mozilla.com/D42868
--HG--
extra : moz-landing-system : lando
The final huge patch. This is a search-and-replace removal of js::Class followed by clang-format and removal of the alias from TypeDecls.h.
Depends on D41986
Differential Revision: https://phabricator.services.mozilla.com/D41987
--HG--
extra : moz-landing-system : lando
JSClass contained void* members corresponding to the internal pointer members of js::Class. This stores the internal members in JSClass and removes js::Class.
This leaves js::Class aliased to JSClass while we remove references to it. I also aliased Jsvalify and Valueify into global scope temporarily to make this compile. These get removed in the following patches.
I had to remove a few functions which now don't compile with js::Class being the same type as JSClass.
Differential Revision: https://phabricator.services.mozilla.com/D41983
--HG--
extra : moz-landing-system : lando
Another big patch. This a search-and-replace followed by mach clang-format, and removal of the js::ClassOps alias from Class.h.
Differential Revision: https://phabricator.services.mozilla.com/D41761
--HG--
extra : moz-landing-system : lando
This removes the original js::ClassOps but leaves it aliased to JSClassOps so everything compiles for now.
Differential Revision: https://phabricator.services.mozilla.com/D41759
--HG--
extra : moz-landing-system : lando
Patch to report JS GC things that are live at shutdown as leaks by calling MOZ_LOG_CTOR for them. The JS engine now clears any remaining roots to prevent dangling pointers to freed memory after shutdown. I made XPCJSRuntime::Shutdown keep the weak pointer update callbacks as sometimes these tables have entries remaining at shutdown (if there are leaks) and we need the callbacks to update them.
This is looking more green on try now.
Differential Revision: https://phabricator.services.mozilla.com/D40449
--HG--
extra : moz-landing-system : lando
There are about the same number of occurrences of "ENABLE_INTL_API" and "EXPOSE_INTL_API"
in the tree, so preferring one over the other doesn't lead to fewer changes. Therefore
I went with "ENABLE_INTL_API", because "ENABLE_" (resp. "MOZ_ENABLE") is already used as
the prefix for other preprocessor ifdef's.
Differential Revision: https://phabricator.services.mozilla.com/D41188
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Sorry for the huge patch. This is pretty much a search and replace of all uses of js::FreeOp.
Differential Revision: https://phabricator.services.mozilla.com/D41412
--HG--
extra : moz-landing-system : lando
Merge js::FreeOp and JSFreeOp, but alias the former to the latter while we fix uses.
Differential Revision: https://phabricator.services.mozilla.com/D41410
--HG--
extra : moz-landing-system : lando
Introduces SweepingTracer and TraceWeakEdge to trace weak references in
AtomsTable::sweep and AtomsTable::sweepIncrementally while sweeping.
Also rename those two functions to traceWeak and traceWeakIncrementally.
Differential Revision: https://phabricator.services.mozilla.com/D40939
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
Remote outer window proxies can't be the target of a CCW, because if
you attempt to wrap them we just create a new outer window proxy.
Therefore, they can't be the target of an Xray wrapper, so they can't
have Xray waivers that do anything useful. However, if we do a
navigation from a local iframe to a remote iframe, we'll transplant a
remote outer window proxy onto a local outer window proxy, which might
have an Xray. This can cause some issues, particularly if we later
navigate back to a different local window.
To work around this, this patch nukes Xray waivers on navigation to a
remote outer window proxy. This makes Xray waiver behavior
inconsistent with the non-Fission behavior, but it is safer to leave
the non-Fission behavior alone for now, for fear of breaking addons.
Differential Revision: https://phabricator.services.mozilla.com/D40116
--HG--
extra : moz-landing-system : lando
Rather than make re-enabling the nursery work correctly (because there's
various ways to disable it and we'd need to make sure we're enabling it for
the right reason). It's simplier just to not disable it for a
gcMaxNurseryBytes of 0, and instead return an error.
Differential Revision: https://phabricator.services.mozilla.com/D39988
--HG--
extra : moz-landing-system : lando
This replaces the original JIT code memory counter with one that tracks the allocated JIT code precisely. This now uses a fixed threshold which was the original intention.
This also removes the INCREMENTAL_MALLOC_TRIGGER GC reason and all GCs triggered by malloc allocations use TOO_MUCH_MALLOC, so whether a GC is incremental is separated from the trigger reason.
Differential Revision: https://phabricator.services.mozilla.com/D39734
--HG--
extra : moz-landing-system : lando
This adds two new parameters. The growth fator is set to 1.5 and the base to 42MB. Trail and error showed that this latter value ended up triggering GCs roughtly in line with the old malloc counter. These values make the initial malloc threshold ~64MB.
Differential Revision: https://phabricator.services.mozilla.com/D39730
--HG--
extra : moz-landing-system : lando
