A lazy self-hosted function has neither a JSScript nor a LazyScript.
This patch adds a SelfHostedLazyScript type with a jitCodeRaw that
allows these functions to called directly by JIT via the interpreter
trampoline. Only one instance per Runtime is needed.
Differential Revision: https://phabricator.services.mozilla.com/D38253
--HG--
extra : moz-landing-system : lando
This helper distinguishes normal lazy functions from lazy self-hosted
funtions which have a nullptr LazyScript. A function may return true for
hasLazyScript but still return a null lazy-script if it has been
partially initialized and is still being accessed such as by GC.
Differential Revision: https://phabricator.services.mozilla.com/D38252
--HG--
extra : moz-landing-system : lando
This is initialized to the same interpreter trampoline as is used for
JSScript::jitCodeRaw. This allows JITs in the future to call scripted
functions that have not been delazified yet.
Differential Revision: https://phabricator.services.mozilla.com/D38251
--HG--
extra : moz-landing-system : lando
My preference was to annotate most of the failing tests with `fail-if` so that
if they start passing, the `fail-if` needs to be removed and they need to keep
passing. That doesn't work for tests that timeout, or which trigger failures
from their cleanup functions, however, so those tests need skip-if. And tests
with fail in their cleanup functions likely leave the browser in an
inconsistent state for subsequent tests, anyway, so really should be skipped
regardless.
There are some remaining tests which still fail because of crashes. I chose
not to skip them here, but to fix the crashes in separate bugs instead.
Differential Revision: https://phabricator.services.mozilla.com/D38247
--HG--
extra : rebase_source : 39ba8fec2e882cfe577c5f2b58ab7e4b461f1178
The changes made in bug changeset 03e0de747d02 assume that drop() is only called on handlers that have been succesfully set on a DebuggerFrame object, and attempt to remove the memory associated with that object. That logic fails if these are called due to an error during initialisation as is happening here. The patch changes a call to drop() to js_delete() and adds assertions that drop() is only called on handlers that are currently associated.
Differential Revision: https://phabricator.services.mozilla.com/D37874
These configurations are already taken care of in js/src/build/moz.build
and do not need to duplicated.
Depends on D37567
Differential Revision: https://phabricator.services.mozilla.com/D37568
--HG--
extra : moz-landing-system : lando
Consolidate build settings required by standalone builds into a single
mozbuild script. A full Gecko build does not use these settings and thus
we cannot simply put them in js/src/build/moz.build
Differential Revision: https://phabricator.services.mozilla.com/D37567
--HG--
extra : moz-landing-system : lando
Got rid of the per-thread JSContext created at the start of each thread. Tasks that require JSContext (ParseTasks, IonBuilder, Wasm tier 2 generators, GCParallel) now request an unused context to set to their thread. Tasks which do not use JSContext will not request one.
Differential Revision: https://phabricator.services.mozilla.com/D37495
--HG--
extra : moz-landing-system : lando
Created a vector of JSContext*, initialized at creation of GlobalHelperThreadState, destroyed when GlobalHelperThreadState.finish() is called. Note that this implementation makes the assumption that the creation and destruction of these objects always happens in the same order (helper thread state created -> main thread context created -> main thread context destroyed -> helper thread state destroyed). In this scenario context checks can clear by each context claiming the main thread during its ctor/dtor but this is only possible if the main thread context is not set at the time.
Also, removed GlobalHelperThreadState::lock() and unlock(), as they are not being used - AutoLockHelperThreadState is used instead.
Differential Revision: https://phabricator.services.mozilla.com/D36842
--HG--
extra : moz-landing-system : lando
Created SetThread/ClearThread functions to handle JSContext/tid setting/clearing & updated existing implementation of JSContext to reflect. CurrentThread is ContextData because JSContext should already have a "claim" on the thread if it's clearing these.
Differential Revision: https://phabricator.services.mozilla.com/D36836
--HG--
extra : moz-landing-system : lando
When using ClearEdgesTracer on PrivateScriptData, we must erase the
types of the GCCellPtr to avoid a number of internal assertions. This is
needed to be able to release PrivateScriptData outside of the JSScript
finalizer.
Differential Revision: https://phabricator.services.mozilla.com/D38024
--HG--
extra : moz-landing-system : lando
This patch should be pure code motion and declaration visibility fixes. There
should be no change in implementation or visible behavior.
Differential Revision: https://phabricator.services.mozilla.com/D37529
--HG--
rename : js/src/dbg/Debugger.cpp => js/src/dbg/Script.cpp
rename : js/src/dbg/Debugger.h => js/src/dbg/Script.h
extra : moz-landing-system : lando
Define a new class, DebuggerScript, inheriting from NativeObject. Move methods
and utility functions into the class as makes sense. Tighten types where
possible on code that works with DebuggerScript objects.
No intended change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D37509
--HG--
extra : moz-landing-system : lando
Just mach clang-tidy fixes. No intended change in implementation or visible behavior.
Differential Revision: https://phabricator.services.mozilla.com/D37508
--HG--
extra : moz-landing-system : lando
This patch should be pure code motion and declaration visibility changes. There
should be no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D37363
--HG--
rename : js/src/dbg/Debugger-inl.h => js/src/dbg/Environment-inl.h
rename : js/src/dbg/Debugger.cpp => js/src/dbg/Environment.cpp
rename : js/src/dbg/Debugger.h => js/src/dbg/Environment.h
extra : moz-landing-system : lando
This patch should be pure code motion and declaration visibility fixes, plus
some formatting changes suggested by clang-tidy. There should be no change in
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D37357
--HG--
rename : js/src/dbg/Debugger-inl.h => js/src/dbg/Frame-inl.h
rename : js/src/dbg/Debugger.cpp => js/src/dbg/Frame.cpp
rename : js/src/dbg/Debugger.h => js/src/dbg/Frame.h
extra : moz-landing-system : lando
This patch should be pure code motion and declaration visibility changes, with
no changes in behavior.
This moves the implementation of Debugger.Objects from js/src/dbg/Debugger.cpp
out into its own file, Object.cpp, with header and inline headers Object.h and
Object-inl.h.
We give js/src/dbg its own moz.build file to avoid object file name collisions
in non-unified builds; see the comments in js/src/dbg/moz.build.
For now, js/src/dbg/moz.build does not use UNIFIED_SOURCES. We will fix that
with a patch at the end of the series.
Differential Revision: https://phabricator.services.mozilla.com/D37336
--HG--
rename : js/src/dbg/Debugger-inl.h => js/src/dbg/Object-inl.h
rename : js/src/dbg/Debugger.cpp => js/src/dbg/Object.cpp
rename : js/src/dbg/Debugger.h => js/src/dbg/Object.h
extra : moz-landing-system : lando
This should just be pure code motion, with no changes to behavior.
Differential Revision: https://phabricator.services.mozilla.com/D37335
--HG--
rename : js/src/dbg/Debugger.cpp => js/src/dbg/NoExecute.h
extra : moz-landing-system : lando
Now that BaselineInterpreterGenerator is also defined there, it's nicer to use the
name of the shared base class.
Differential Revision: https://phabricator.services.mozilla.com/D38174
--HG--
rename : js/src/jit/BaselineCompiler.cpp => js/src/jit/BaselineCodeGen.cpp
rename : js/src/jit/BaselineCompiler.h => js/src/jit/BaselineCodeGen.h
extra : moz-landing-system : lando
Our previous representation of private values assumed that the private pointer was aligned, and did some bit twiddling to try to disguise it as a double. Since bug 1293313, it has been unnecessary to set the top bit for a double, so that bit twiddling is unnecessary. There are actual use cases where private values are unaligned, so we should fix this.
While cleaning this up, I also removed unboxPrivateValue, because its only use could be better written using loadPrivateValue directly.
Differential Revision: https://phabricator.services.mozilla.com/D38127
--HG--
extra : moz-landing-system : lando
When flags are derived from the FunctionBox, we should consistently set
them for both LazyScript and JSScript even if their primary use it
hinting delazification.
Differential Revision: https://phabricator.services.mozilla.com/D38207
--HG--
extra : moz-landing-system : lando
This flag is only checked by the eval-cache which currently disallows
*any* inner function/object. If the HasSingletons flag was set, we'd
already have inner objects so the effect is still the same without.
Differential Revision: https://phabricator.services.mozilla.com/D38092
--HG--
extra : moz-landing-system : lando
We used the BaselineDebugModeOSRInfo "continuation fixer" mechanism for those
but we don't have to. CallVMs are very similar to ICs and we should treat them
the same way (patch return address based on RetAddrEntry).
This is preparation for removing BaselineDebugModeOSRInfo completely: with this
change it's only used for the optional debug-instrumentation callVMs and those
will just resume in the interpreter where we always have those callVMs.
Differential Revision: https://phabricator.services.mozilla.com/D38056
--HG--
extra : moz-landing-system : lando
Also reorder functions in OffThreadScriptCompilation to group by
data source type.
Differential Revision: https://phabricator.services.mozilla.com/D37575
--HG--
extra : moz-landing-system : lando
This has equivalent overall behavior as before, but computes the
precise LazyScript::TreatAsRunOnce flag rather than checking the extra
conditions during delazification. The heuristics can be computed using
just the LazyScript information so the result is the same.
Differential Revision: https://phabricator.services.mozilla.com/D38025
--HG--
extra : moz-landing-system : lando
Decouple the JSScript creation for delazification from needing
CompileOptions. When JSScript and LazyScript become unified, this
operation will become a no-op.
Differential Revision: https://phabricator.services.mozilla.com/D38023
--HG--
extra : moz-landing-system : lando
With the current design of ImmutableScriptData, even empty arrays have a
legal span so we no longer need to change the hasTryNotes and friends
helpers. In most cases we were performing a range-for afterwards so this
has simpler semantics.
Differential Revision: https://phabricator.services.mozilla.com/D37882
--HG--
extra : moz-landing-system : lando
The 50 threshold for Baseline is pretty arbitrary and will likely change later.
Differential Revision: https://phabricator.services.mozilla.com/D37214
--HG--
extra : moz-landing-system : lando
We no longer need the early-check mechanism if we always do environment chain
initialization + stack check before initializing locals. A comment mentions that
environment initialization can only happen _after_ pushing locals, but that
didn't match the code anyway: if the early stack check failed, we would end up
in initEnvironmentChain _without_ having initialized locals.
Ion prologue bailouts now resume in the prologue after environment chain
initialization, so the bailout code needed some small changes to always
initialize the environment chain instead of relying on the Baseline
prologue doing that.
Overall this is much simpler and deletes about 70 lines of code.
Differential Revision: https://phabricator.services.mozilla.com/D37566
--HG--
extra : moz-landing-system : lando
Because ShouldIncludeEdge considers the |origin| node as well, it was possible for
the old code to 'miss' nodes and never write them to the core dump even though we
also wrote some edges with the node as referent.
Differential Revision: https://phabricator.services.mozilla.com/D37701
--HG--
extra : moz-landing-system : lando
XDR should be a structural clone, so check if we have a lazy script
directly when deciding if it should be coded. Whether relazification
should be supported is a VM decision, not an XDR decision. This gives a
cleaner round-trip of data when using XDR.
Differential Revision: https://phabricator.services.mozilla.com/D37578
--HG--
extra : moz-landing-system : lando
* Remove double spaces after periods.
* Add periods at the end of sentances.
* Fix a spelling error.
* Use a simpler sentance.
Differential Revision: https://phabricator.services.mozilla.com/D37366
--HG--
extra : moz-landing-system : lando
After this patch a JSScript will have Private, Runtime, and Immutable
script data type attached to it.
Differential Revision: https://phabricator.services.mozilla.com/D37867
--HG--
extra : moz-landing-system : lando
Add an 'Offset' type-alias to better document as well as fixing up
out-of-date comments. This also moves the optArrayOffset to beginning of
structure.
Differential Revision: https://phabricator.services.mozilla.com/D37866
--HG--
extra : moz-landing-system : lando
This optimisation added to the specification doesn't improve performance for us,
because we're already optimising the lookups in Promise.all & co. So we only
need to perform the initial check for `PromiseLookup::isDefaultPromiseState`
outside of the main loop in `CommonPerformPromiseAllRace` and that's more or
less all what needs to be changed.
Differential Revision: https://phabricator.services.mozilla.com/D37531
--HG--
extra : moz-landing-system : lando
This records the size of the heap at the start of collection and maintains a count of bytes freed during collection. From this we calcuate a 'survival rate' at the end of collection. The intention is that this is like the nursery's promotion rate so it's the fraction retained rather than the fraction freed.
Differential Revision: https://phabricator.services.mozilla.com/D37452
Factor out methods to send GC telemetry at the end of a slice and at the end of a collection. Rename heap size fields to indicate that they are for total heap size in bytes as opposed to the size of collected zones.
Differential Revision: https://phabricator.services.mozilla.com/D37451
Negative zero can be treated the same way as positive zero for MInArray,
MStoreTypedArrayElementHole, and MPostWriteElementBarrier. This avoids possible negative zero
bailouts for these operations.
Depends on D37260
Differential Revision: https://phabricator.services.mozilla.com/D37261
--HG--
extra : moz-landing-system : lando
Use the correct index position for MStoreElementHold and MFallibleStoreElement to avoid possible
negative zero bailouts for these operations.
Depends on D37259
Differential Revision: https://phabricator.services.mozilla.com/D37260
--HG--
extra : moz-landing-system : lando
The string representation of negative zero is equal to the one for positive zero, so there's no
need to call into the runtime for that case.
Differential Revision: https://phabricator.services.mozilla.com/D37259
--HG--
extra : moz-landing-system : lando
When we shrink the nursery below one chunk, poison and mark as inaccessible
the now unused part of that chunk.
This is the only patch in this patch series that adds extra memory poisoning.
Differential Revision: https://phabricator.services.mozilla.com/D37348
--HG--
extra : moz-landing-system : lando
This restores the use of GC invocation kind that was inadvertantly removed by the patch in bug 1395509 comment 33 from the call to ZoneAllocator::updateAllGCThresholds in GCRuntime::endSweepingSweepGroup. Also refactors ZoneMallocThreshold::computeZoneTriggerBytes a little.
Differential Revision: https://phabricator.services.mozilla.com/D36924
Updating these process-wide prefs at runtime is racy, it was easy to get
into a weird state and we bake in some of these values in JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D37387
--HG--
extra : moz-landing-system : lando
Using process-wide prefs is consistent with the other JIT options and is simpler
to work with (one place to initialize for all runtimes).
Differential Revision: https://phabricator.services.mozilla.com/D37385
--HG--
extra : moz-landing-system : lando
- The new formatted-value API is still draft-only, so extra U_HIDE_DRAFT_API guards
are currently needed.
- Also moves steps 4-5 of PartitionRelativeTimePattern to native code to reduce code
duplication.
Differential Revision: https://phabricator.services.mozilla.com/D26719
--HG--
extra : moz-landing-system : lando
Add js::intl::NumberFormatFields containing the two methods:
- `append`: To append a number format field
- `toArray`: To construct the result Array object
The `unitType` argument for NumberFormatFields::toArray will be used in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D26718
--HG--
extra : moz-landing-system : lando
- Part 3 uses functions added in ICU 64, so we need to bump the version requirement.
- Also remove a version check which is now true be default.
Differential Revision: https://phabricator.services.mozilla.com/D26717
--HG--
extra : moz-landing-system : lando
Thinko: I did this for codeCoverageAtPCLabel but codeCoverageAtPrologueLabel
also needs to do this because the pc register has been initialized before that.
This fixes code coverage jit-tests on arm64.
Depends on D37210
Differential Revision: https://phabricator.services.mozilla.com/D37211
--HG--
extra : moz-landing-system : lando
This test lowers the Ion threshold to 50, conflicting with the new Baseline
threshold of 50.
Depends on D37209
Differential Revision: https://phabricator.services.mozilla.com/D37210
--HG--
extra : moz-landing-system : lando
This prevents slowdowns when we increase the Baseline JIT threshold and
is more predictable when we move BaselineCompiler off-thread.
Differential Revision: https://phabricator.services.mozilla.com/D36906
--HG--
extra : moz-landing-system : lando
Instead of initializing frame->environmentChain to nullptr first and then setting it to
fun->environment() later, we can store fun->environment immediately. This also means the
interpreter doesn't need to load and untag the callee token a second time.
Differential Revision: https://phabricator.services.mozilla.com/D36904
--HG--
extra : moz-landing-system : lando
DebuggerFrame::eval and DebuggerObject::evalInGlobal are two more invocation
functions that can reasonably use Completion to report the results of the
operation.
Differential Revision: https://phabricator.services.mozilla.com/D33077
--HG--
extra : moz-landing-system : lando
Replacing more calls to Debugger::resultToCompletion with uses of the newer API.
Differential Revision: https://phabricator.services.mozilla.com/D33076
--HG--
extra : moz-landing-system : lando
Use the `Completion` type to report the result of the
`DebuggerObject::setProperty` and `getProperty` methods.
Differential Revision: https://phabricator.services.mozilla.com/D25097
--HG--
extra : moz-landing-system : lando
This patch introduces a new type to the debugger, `js::Completion`, describing
how a given JavaScript evaluation completed. It's a wrapper around a `Variant`
with alternatives:
- Return
- Throw
- Terminate
- InitialYield (the initial yield of a generator, returning the generator object)
- Yield (subsequent yields of a generator)
- Await (both initial and subsequent)
We can construct a `Completion` in two ways:
- From any JavaScript operation's result (a success value and a context carrying
an exception value and stack). This only distinguishes between Return, Throw,
and Terminate.
- From a stack frame that's about to be popped. This allows us to identify
yields and awaits.
Given a `Completion` we can construct Debugger API 'completion values' to pass
to hooks, as well as the resumption/value/context states that tell the engine
how to continue execution. Within Debugger itself, `Completion` values are a
convenient place to gather up various bits of logic: identifying suspensions,
chaining resumption values from multiple Debugger hooks, and so on.
Although `Completion` should be used throughout Debugger, this patch only uses
it for the `onPop` hook. Subsequent patches in the series will apply it to other
cases where Debugger can invoke JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D24997
--HG--
extra : moz-landing-system : lando
DebuggerFrame::eval and DebuggerObject::evalInGlobal are two more invocation
functions that can reasonably use Completion to report the results of the
operation.
Differential Revision: https://phabricator.services.mozilla.com/D33077
--HG--
extra : moz-landing-system : lando
Replacing more calls to Debugger::resultToCompletion with uses of the newer API.
Differential Revision: https://phabricator.services.mozilla.com/D33076
--HG--
extra : moz-landing-system : lando
Use the `Completion` type to report the result of the
`DebuggerObject::setProperty` and `getProperty` methods.
Differential Revision: https://phabricator.services.mozilla.com/D25097
--HG--
extra : moz-landing-system : lando
This patch introduces a new type to the debugger, `js::Completion`, describing
how a given JavaScript evaluation completed. It's a wrapper around a `Variant`
with alternatives:
- Return
- Throw
- Terminate
- InitialYield (the initial yield of a generator, returning the generator object)
- Yield (subsequent yields of a generator)
- Await (both initial and subsequent)
We can construct a `Completion` in two ways:
- From any JavaScript operation's result (a success value and a context carrying
an exception value and stack). This only distinguishes between Return, Throw,
and Terminate.
- From a stack frame that's about to be popped. This allows us to identify
yields and awaits.
Given a `Completion` we can construct Debugger API 'completion values' to pass
to hooks, as well as the resumption/value/context states that tell the engine
how to continue execution. Within Debugger itself, `Completion` values are a
convenient place to gather up various bits of logic: identifying suspensions,
chaining resumption values from multiple Debugger hooks, and so on.
Although `Completion` should be used throughout Debugger, this patch only uses
it for the `onPop` hook. Subsequent patches in the series will apply it to other
cases where Debugger can invoke JavaScript.
Differential Revision: https://phabricator.services.mozilla.com/D24997
--HG--
extra : moz-landing-system : lando
This is both simpler and faster than the old scheme where the pc was stored in
a register but could be clobbered by R2.
On x64 this wins about 9-10%. On 32-bit x86 we don't have enough registers so
there we load the pc from the frame in more cases. That's about a 2-3%
regression and is a reasonable trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D36583
--HG--
extra : moz-landing-system : lando
After the recent script data changes we can now read objects/scopes/bigints and resume offsets
from JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D36201
--HG--
extra : moz-landing-system : lando
Stop inserting DebuggeeFrameGeneratorScript keys in the cross-compartment
wrapper table for the edges from Debugger.Frames for generator / async calls to
the generators' scripts. The wrappers are unnecessary, and since they're not
unique when multiple Debugger.Frames refer to different calls of the same
generator, we can't easily tell when to remove them.
Differential Revision: https://phabricator.services.mozilla.com/D35617
--HG--
extra : moz-landing-system : lando
This replaces SystemAllocPolicy with ZoneAllocPolicy for things related to zones where possible. There are a few places where this isn't possible at the moment due to header include order. I'll try and revisit these later after removing the current malloc memory tracking as this simplifies the situation.
Differential Revision: https://phabricator.services.mozilla.com/D36923
If we make the output pointer optional we can use SweepActionForEach in place of SweepAtionRepeatFor and remove the latter.
Differential Revision: https://phabricator.services.mozilla.com/D37226
This makes looping constucts take an out parameter to store the loop iteration value in. This gets rid of RemoveLastTemplateParameter which I enjoyed writing but always felt guitly about inflicting on the world.
Differential Revision: https://phabricator.services.mozilla.com/D37224
This class will not just decommit whole chunks, so rename it to not imply
that as much.
Differential Revision: https://phabricator.services.mozilla.com/D35589
--HG--
extra : moz-landing-system : lando
Also change the temporary buffer to a normal Array to ensure the `Merge` helper
is called with the same object class.
Differential Revision: https://phabricator.services.mozilla.com/D24712
--HG--
extra : moz-landing-system : lando
To not make jstests even slower, this adds --jitflags=jstests and uses it for
jstests in automation. For jstests we can use fewer jit configurations than
for jit-tests.
This also removes the bigint and bigintdebug autospider variants. BigInt is now
enabled by default so we no longer need the configure flag etc.
Differential Revision: https://phabricator.services.mozilla.com/D36307
--HG--
extra : moz-landing-system : lando
This is consistent with IsBaselineEnabled/IsIonEnabled and lets us handle the
JS_CODEGEN_NONE and no-floating-point-support cases the same way.
Differential Revision: https://phabricator.services.mozilla.com/D36472
--HG--
extra : moz-landing-system : lando
This is process-wide state and storing it in JSContext/JSRuntime requires
callers to pass a context/runtime for no good reason. This simplifies the
next patch.
Storing this in JitOptions seemed nicer than adding new globals for this and
maybe in the future we will have a testing function/flag to toggle these
flags.
Differential Revision: https://phabricator.services.mozilla.com/D36471
--HG--
extra : moz-landing-system : lando
This avoids overrecursion exceptions on testManyVars.js on Windows/Linux
(the C++ interpreter has heap-allocated stack frames so it can handle this
better).
Differential Revision: https://phabricator.services.mozilla.com/D36469
--HG--
extra : moz-landing-system : lando
It needs to set resumePCinCurrentFrame_ to an address in the interpreter JitCode
instead of nullptr (or else the profiler's JitCodeMap lookup will assert).
Differential Revision: https://phabricator.services.mozilla.com/D36468
--HG--
extra : moz-landing-system : lando
The last part of my local interpreter patch stack that's necessary to pass jit-tests.
Differential Revision: https://phabricator.services.mozilla.com/D36306
--HG--
extra : moz-landing-system : lando
This also has some minor changes to allow enabling the Baseline Interpreter without
the Baseline JIT.
After this is enabled by default we want to make the Interpreter a hard dependency
for Baseline (similar to how Ion requires Baseline to be enabled) and then we can
simplify some code, but of course we can't do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D31038
--HG--
extra : moz-landing-system : lando
The patch switches some ctypes data structures to ZoneAllocPolicy so that their memory use is tracked against the zone. The creation of heapHash in StructType::DefineInternal relies on the ZoneAllocPolicy being movable after having memory accounted to it.
Differential Revision: https://phabricator.services.mozilla.com/D36178
Patch to allow ZoneAllocPolicy insstance to be moved after having memory accounted to it. This is useful in the situation where a data structure is populated before being attached to a GC thing by moving it. The code will currently assert (in unregisterPolicy()) if a ZoneAllocPolicy is copied after having memory accounted to it. This could be allowed but it seems better to force users to move in this situation.
Differential Revision: https://phabricator.services.mozilla.com/D36177
- Update Intl.PluralRules to use UNumberFormatter, similar to the updates in part 1.
- Cache the UFormattedNumber instance to turn a performance regression into a
performance improvement.
Differential Revision: https://phabricator.services.mozilla.com/D27084
--HG--
extra : moz-landing-system : lando
- Add NumberFormatterSkeleton as a helper class to construct a number formatter
skeleton. When the "Intl.NumberFormat Unified API" proposal gets implemented
a more feature-rich class may be necessary.
- In addition to a UNumberFormatter instance, NumberFormatObject now also
stores a UFormattedNumber instance. This avoids a performance regression
compared to creating a new UFormattedNumber object each time a number gets
formatted. (In micro-benchmarks 20% regressions were seen, with a cached
UFormattedNumber the same micro-benchmarks even improved by ~33%.)
- Add accessors for reserved slot values to NumberFormatObject to improve
readibility.
Differential Revision: https://phabricator.services.mozilla.com/D27083
--HG--
extra : moz-landing-system : lando
Add memory tracking for various debugger objects. Since the Handler class forms an interface I added a virtual allocSize() method to allow subclasses to supply their size. This is possibly overkill.
Differential Revision: https://phabricator.services.mozilla.com/D35797
The memory tracking needs the GC thing so I made WasmBreakpointSite hold a pointer to the Instance rather than just the DebugState. I added DebugState::getBreakpointSite for cases were we already expect this to exist, like JSScript::getBreakpointSite.
Differential Revision: https://phabricator.services.mozilla.com/D35795
The memory tracking needs the GC thing so I made WasmBreakpointSite hold a pointer to the Instance rather than just the DebugState. I added DebugState::getBreakpointSite for cases were we already expect this to exist, like JSScript::getBreakpointSite.
Differential Revision: https://phabricator.services.mozilla.com/D35795
Both of these functions are now split into SharedScriptData and
RuntimeScriptData variants.
Differential Revision: https://phabricator.services.mozilla.com/D36354
--HG--
extra : moz-landing-system : lando
This results in SharedScriptData having no pointers left and being an
easy candidate for sharing accross procecces.
The XDR and InitFromEmitter functions will be split in follow-up patches
to make the changes easier to follow.
Differential Revision: https://phabricator.services.mozilla.com/D36353
--HG--
extra : moz-landing-system : lando
This splits the ref-count off from js::SharedScriptData. The JSScript
points to the RuntimeScriptData which points to the SharedScriptData.
This is precursor work to allowing script data to be shared between
processes.
Differential Revision: https://phabricator.services.mozilla.com/D36352
--HG--
extra : moz-landing-system : lando
Relax the allowed input type for `String.fromCodePoint` from Int32 to any Number type, so that a
missed Int32 optimisation for the input argument doesn't prevent inlining the complete function.
MToNumberInt32 triggers a bailout when the input isn't representable as an Int32 value, but since
`String.fromCodePoint` will throw an exception in this case anyway, it's okay when MToNumberInt32
bails out earlier.
Differential Revision: https://phabricator.services.mozilla.com/D37265
--HG--
extra : moz-landing-system : lando
- The new formatted-value API is still draft-only, so extra U_HIDE_DRAFT_API guards
are currently needed.
- Also moves steps 4-5 of PartitionRelativeTimePattern to native code to reduce code
duplication.
Differential Revision: https://phabricator.services.mozilla.com/D26719
--HG--
extra : moz-landing-system : lando
Add js::intl::NumberFormatFields containing the two methods:
- `append`: To append a number format field
- `toArray`: To construct the result Array object
The `unitType` argument for NumberFormatFields::toArray will be used in part 3.
Differential Revision: https://phabricator.services.mozilla.com/D26718
--HG--
extra : moz-landing-system : lando
- Part 3 uses functions added in ICU 64, so we need to bump the version requirement.
- Also remove a version check which is now true be default.
Differential Revision: https://phabricator.services.mozilla.com/D26717
--HG--
extra : moz-landing-system : lando
The other caller of EnsureBareExitFrame is when unwinding in the exception
handler and we already call deleteDebugModeOSRInfo there.
Differential Revision: https://phabricator.services.mozilla.com/D36759
--HG--
extra : moz-landing-system : lando
This test has questionable value but this just makes it
faster by reducing iteration count.
Differential Revision: https://phabricator.services.mozilla.com/D36745
--HG--
extra : moz-landing-system : lando
Convert ThreadData to ContextData in JSContext. Removed some old GCHelperState variables that are no longer being used. Removed NativeStackQuota, which is never read. Renamed SetNativeStackQuotaAndLimit to SetNativeStackLimit, as it is never setting a NativeStackQuota.
Differential Revision: https://phabricator.services.mozilla.com/D36533
--HG--
extra : moz-landing-system : lando
Adds CheckContextLocal protected data checks and a data type to check a JSContext against the TlsContext of the thread. Objects must specify the JSContext in which they are created in to check against.
Differential Revision: https://phabricator.services.mozilla.com/D36518
--HG--
extra : moz-landing-system : lando
The sharedMemoryEnabled attribute of the module environment is not a
boolean, but a true/false enum, and must be tested through an explicit
comparison with one of the enum values.
Differential Revision: https://phabricator.services.mozilla.com/D36619
--HG--
extra : moz-landing-system : lando
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 941298157e7c82f420cf50ce057154ce9b85301c
extra : source : 189dc8a359815e059a4a217f788d183260bb2bfe
The SpecialPowers set*Pref/get*Pref APIs currently use synchronous messaging
to set and get preference values from the parent process. Aside from directly
affecting callers of those APIs, it also affects callers of `pushPrefEnv`,
which is meant to be asynchronous, but is in practice usually synchronous due
to the synchronous messaging it uses.
This patch updates the getPref APIs to use the in-process preference service
(which most callers are expecting anyway), and also updates the callers of
the setPref and pushPrefEnv APIs to await the result if they're relying on it
taking effect immediately.
Unfortunately, there are some corner cases in tests that appear to only work
because of the quirks of the current sync messaging approach. The synchronous
setPref APIs, for instance, trigger preference changes in the parent
instantly, but don't update the values in the child until we've returned to
the event loop and had a chance to process the notifications from the parent.
The differnce in timing leads some tests to fail in strange ways, which this
patch works around by just adding timeouts.
There should be follow-ups for test owners to fix the flakiness.
Differential Revision: https://phabricator.services.mozilla.com/D35054
--HG--
extra : rebase_source : 9c7cc853a635b6e94b6c89db0bd045384b58e552
This allows using the CRANELIFT_FLAGS environment variable to control some
flags. To start with, this allows selecting the optimization level (opt_level,
which can be set to fastest/default/best as of this date) and
enabling/disabling jump tables.
Differential Revision: https://phabricator.services.mozilla.com/D36322
--HG--
extra : rebase_source : 1c61676e891efc21605e45a9f47d01c4837a7430
extra : histedit_source : 9c0fc5bd2167b4d71b390ef1e563ac8bd0c91f18
- rename the cpu.rs file to isa.rs;
- create a new function for platform-specific flags, and move x86 flags in
there;
Differential Revision: https://phabricator.services.mozilla.com/D36321
--HG--
rename : js/src/wasm/cranelift/src/cpu.rs => js/src/wasm/cranelift/src/isa.rs
extra : rebase_source : 2611faa2084f82667e73cc264c10ba6f7c97c407
extra : histedit_source : f1db60e45ea7a3178c19153912d2c659c10f7f71
This introduces a bindings module in the cranelift bindings directory, to make
the roles of different files clearer:
- bindings/low_level.rs (formerly known as baldrapi.rs) contains all the
bindings automatically generated by bindgen.
- bindings/mod.rs (formerly known as baldrdash.rs) contains all the high-level
bindings, to be used by the rest of baldrdash.
Some code has been moved to match the roles more consistently; in particular,
nothing in bindings/low_level should be directly used from outer the bindings
directory.
Rustfmt has been run too, which explains a few unrelated changes.
Differential Revision: https://phabricator.services.mozilla.com/D36319
--HG--
rename : js/src/wasm/cranelift/src/baldrapi.rs => js/src/wasm/cranelift/src/bindings/low_level.rs
rename : js/src/wasm/cranelift/src/baldrdash.rs => js/src/wasm/cranelift/src/bindings/mod.rs
extra : rebase_source : b6a111cb9f8909e7872aa43452228194d81f79cd
extra : histedit_source : c774c2c4ab98e24aca637451bb0d1fd03d0b94f3
WebRender being on or off doesn't affect the JIT code, so the option is
not really useful in this harness. However, it is a downstream harness that
we'll be passing this flag to so for consistency we have it accept the
flag and silently eat it.
Differential Revision: https://phabricator.services.mozilla.com/D35865
--HG--
extra : moz-landing-system : lando
The nursery isn't exactly swept, but it is evicted. Name this function to
make it match its context better.
Differential Revision: https://phabricator.services.mozilla.com/D36316
--HG--
extra : moz-landing-system : lando
HandleDebugTrap calls DebugAfterYield, which can call the onEnterFrame debugger hook.
This hook can mess with debugger state so HandleDebugTrap needs to be a bit more
careful with its assertions.
Differential Revision: https://phabricator.services.mozilla.com/D36209
--HG--
extra : moz-landing-system : lando
Merge Debugger::addGeneratorFrame into DebuggerFrame::setGenerator, and expand
the role of clearGenerator to fully undo the effect of setGenerator.
The association between a Debugger.Frame referring to a generator or async call
and the underlying generator object must be recorded in five separate places, as
a transaction: either all or present, or none are present. To ensure this is
true, this patch places sole responsibility for emplacing all those relations in
a single function (setGenerator), with another function to tear down those
relations (clearGenerator) as its inverse/antidote/complement/antagonist (in the
anatomical sense)/what-have-you.
Actually, when a Debugger.Frame is GC'd, we cannot reliably undo some of the
connections, and in fact can let the GC take care of those for us, so the
tear-down function clearGenerator is split into two overloads, one which is
suitable for use from a finalizer and the other which takes care of the entire
task.
Differential Revision: https://phabricator.services.mozilla.com/D35607
--HG--
extra : moz-landing-system : lando
Later in this patch series, we will be gathering up all the code to manage the
association between DebuggerFrame and AbstractGeneratorFrame objects into a pair
of functions, one to establish a relation and the other to tear it down. The
removeif method combines iteration and entry removal, but we would rather have
entry removal live next to the code that tears down the rest of the association.
In preparation for that, this changeset replaces the sole use of removeIf with
its (not very large) definition, so that the entry removal can be more readily
moved into another function.
Differential Revision: https://phabricator.services.mozilla.com/D35606
--HG--
extra : moz-landing-system : lando
Without this patch, addGeneratorFrame may be called from any realm, and enters
the debugger's realm to call DebuggerFrame::setGenerator. However, we would like
to merge addGeneratorFrame and setGenerator, and call the combined from various
points which are already in the debugger's realm, so it would be a little nicer
to simply make the function assume it is called from the debugger's realm.
Differential Revision: https://phabricator.services.mozilla.com/D35605
--HG--
extra : moz-landing-system : lando
The hand-written assembly for libffi on aarch64/windows doesn't emit
unwind information. If we ever tried to unwind through these functions,
they'd look like leaf functions, which is decidedly not true and would
cause great pain.
For whatever reason, the original aarch64 libffi functions used
x21/x22/x23/x24 as their (callee-saved) scratch registers. This
convention works on windows as well, but the unwind information on
windows mandates that we start saving callee-saved registers starting
from x19, rather than x21. Rather than rewriting the assembly to use
x19/x20 instead of x21/x22, which would be a large change, we chose
instead to simply save/restore extra registers in the prolog/epilog.
This change does make the stack frame sizes slightly bigger, but an
extra 16 bytes in libffi stack frames should not matter.
The `-TC` change is necessary to make the compiler play nicely with .asm
file suffixes.
Differential Revision: https://phabricator.services.mozilla.com/D35714
--HG--
extra : moz-landing-system : lando
Ted Campbell
Ciure Andrei
Jeff Walden
Paul Bone
Kris Maglione
Jon Coppeard
Razvan Maries
Kristen Wright
André Bargull
Jim Blandy
Jan de Mooij
Iain Ireland
Tom Ritter
Sylvestre Ledru
Boris Zbarsky
Andreea Pavel
Daniel Varga
Csoregi Natalia
Brindusan Cristian
Tooru Fujisawa
Brian Hackett
Andrew Halberstadt
Cosmin Sabou
Adam Holm
arthur.iakab
Barret Rennie
Mu Tao
Jed Davis
Gurzau Raul
Nicholas Nethercote
Mihai Alexandru Michis
Narcis Beleuzu
Sebastian Hengst
Dorel Luca
Kershaw Chang
Emilio Cobos Álvarez
Tom Schuster
Jonathan Kingston
Greg Tatum
Edwin Gao
Victor Porof
Jorg K
Oana Pop Rus
Benjamin Bouvier
Matthew Gaudet
Lars T Hansen
Karan Sapolia
Cameron Kaiser
Ross Kirsling
Andrea Marchesini
shindli
Kartikaya Gupta
Kagami Sascha Rosylight
Christian Holler
Mike Hommey
Ashley Hauck
Jason Orendorff
Nathan Froyd
Andy Wingo