This releases all foreground finalized arenas at the end of sweeping the sweep group rather than at the end of sweeping the zone (for objects) or immediately (for everything else) as happens currently. This simplifies the code in a couple of places and I don't think it will have any noticeable effects.
Differential Revision: https://phabricator.services.mozilla.com/D31415
This removes a bunch of repeated code and hopefully makes it easier to see what we're testing. When marking two things the same color this now checks both orders (e.g. key before map, map before key). I removed individual test cases and generate all possiblities with for loops. The expected marking state is determined by functions factored out from the verifier.
The tests for JS WeakMap and internal weakmaps are slightly different because I wanted to cover all existing test cases without making things too complicated. This means we don't test marking the key and delegate different colors for the former.
Differential Revision: https://phabricator.services.mozilla.com/D30948
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
Make T as a strictness marker for ISO8601 time element, as it already does for the date element.
Differential Revision: https://phabricator.services.mozilla.com/D31418
--HG--
extra : moz-landing-system : lando
...longest code point encoding - 1) + ColumnChunkLength - 1 units must be observed when computing a column number. r=arai
Depends on D31301
Differential Revision: https://phabricator.services.mozilla.com/D31302
--HG--
extra : moz-landing-system : lando
Amend several test files for triggering eval() assertion through simpletest.js
Differential Revision: https://phabricator.services.mozilla.com/D30474
--HG--
extra : moz-landing-system : lando
This matches what we do for C++-interpreter frames in CollectInterpreterStackScripts and
SkipInterpreterFrameEntries. It's necessary for Interpreter => JIT OSR to work correctly.
This fixes remaining jit-test failures with --blinterp-eager
Differential Revision: https://phabricator.services.mozilla.com/D31050
--HG--
extra : moz-landing-system : lando
ES5.1 removed time-only format T00:00:00 and no other browsers support it. So this diff removes the support from gecko.
Differential Revision: https://phabricator.services.mozilla.com/D31253
--HG--
extra : moz-landing-system : lando
The code in NewArgumentsObject was wrong because the interpreter code calling it
also relies on the analysis having been performed.
Differential Revision: https://phabricator.services.mozilla.com/D30899
--HG--
extra : moz-landing-system : lando
1. We can't use loadValue for JSOP_DOUBLE because on ARM that might use LDRD or
LDM and these are not guaranteed to support unaligned loads. Fix is to add
loadUnalignedValue that always uses plain 32-bit loads.
2. DebugTrapHandler's fast path for the interpreter used "lr" as second scratch
register, clobbering the return address. The setSecondScratchRegister mechanism
prevents this.
Differential Revision: https://phabricator.services.mozilla.com/D30879
--HG--
extra : moz-landing-system : lando
This is a basic threaded interpreter design. Performance is pretty good but we
can optimize it more in the future when everything else is in place.
Differential Revision: https://phabricator.services.mozilla.com/D30370
--HG--
extra : moz-landing-system : lando
This change introduces a new dll, vrhost, to make it easier to share
VR code across multiple process.
An executable, vrtesthost, is also added for testing purposes to
validate the DLL loads in a minimal environment.
Differential Revision: https://phabricator.services.mozilla.com/D30653
--HG--
extra : moz-landing-system : lando
This is preliminary work to allowing encoding of JSCVTFP, the instruction that exists on new AArch64 devices that greatly speeds up websites that use floating-point math.
Differential Revision: https://phabricator.services.mozilla.com/D30997
--HG--
extra : moz-landing-system : lando
The code in NewArgumentsObject was wrong because the interpreter code calling it
also relies on the analysis having been performed.
Differential Revision: https://phabricator.services.mozilla.com/D30899
--HG--
extra : moz-landing-system : lando
1. We can't use loadValue for JSOP_DOUBLE because on ARM that might use LDRD or
LDM and these are not guaranteed to support unaligned loads. Fix is to add
loadUnalignedValue that always uses plain 32-bit loads.
2. DebugTrapHandler's fast path for the interpreter used "lr" as second scratch
register, clobbering the return address. The setSecondScratchRegister mechanism
prevents this.
Differential Revision: https://phabricator.services.mozilla.com/D30879
--HG--
extra : moz-landing-system : lando
This function probably predates the existence of the DebuggerFrame class, and
was never moved in.
Depends on D28785
Differential Revision: https://phabricator.services.mozilla.com/D28786
--HG--
extra : moz-landing-system : lando
Tracelogger is no longer functioning properly because of bad script event ids. The baselinescript load into scratch1 was accidentally removed leading garbage script ids to be passed into emitTraceLoggerResume. This fix aims to simply reload the correct value back into scratch1 before calling tracelogger.
Differential Revision: https://phabricator.services.mozilla.com/D30680
--HG--
extra : moz-landing-system : lando
We can run /debug mochitests against geckoview for the cost of another dozen
or so test annotations. Both /opt and /debug mochitests are nearly worthy of
tier 1, but still waiting for bug 1534732.
Differential Revision: https://phabricator.services.mozilla.com/D30931
--HG--
extra : moz-landing-system : lando
The semantics are that you get an empty array if the argument is not supplied,
and if [optional_argc] is used it's set accordingly so you can tell whether you
were passed explicit [] or not passed anything.
Differential Revision: https://phabricator.services.mozilla.com/D30850
--HG--
extra : moz-landing-system : lando
Fix possible race condition where an atomic field that may be concurrently modified is referenced twice in an assertion expression.
Differential Revision: https://phabricator.services.mozilla.com/D30891
--HG--
extra : moz-landing-system : lando
These function probably predate the existence of the DebuggerFrame class, and
were never moved in.
Depends on D28784
Differential Revision: https://phabricator.services.mozilla.com/D28785
--HG--
extra : moz-landing-system : lando
This function probably predates the existence of the DebuggerFrame class, and
was never moved in.
Depends on D28783
Differential Revision: https://phabricator.services.mozilla.com/D28784
--HG--
extra : moz-landing-system : lando
SpiderMonkey standard practice for classes derived from JSObject defines
ClassOps hooks as static member functions.
Depends on D28782
Differential Revision: https://phabricator.services.mozilla.com/D28783
--HG--
extra : moz-landing-system : lando
This replaces the use of heap-alloced Rooted with PersistentRooted which is safe wrt destruction order.
I had to add PersistentRooted and StackGCVector to OPAQUE_TYPES to make this work... I'm not really sure what this does.
Differential Revision: https://phabricator.services.mozilla.com/D30668
--HG--
extra : moz-landing-system : lando
If the Debugger API tries to inspect or modify an IonMonkey frame, much of
the information it expects to find in a frame is missing: function calls
may have been inlined, variables may have been optimized out, and so on. So
when this happens, SpiderMonkey builds one or more Rematerialized frames
from the IonMonkey frame, using metadata built by Ion to reconstruct the
missing parts. The Rematerialized frames are now the authority on the state
of those frames, and the Ion frame is ignored: stack iterators ignore the
Ion frame, producing the Rematerialized frames in their stead; and when
control returns to the Ion frame, we pop it, rebuild Baseline frames from
the Rematerialized frames, and resume execution in Baseline.
Thus, Rematerialized frames are always created with their
hasCachedSavedFrame bits clear: although there may be extant SavedFrames
built from the original IonMonkey frame, the Rematerialized frames will not
have cache entries for them until they are traversed in a capture themselves.
This means that, oddly, it is not always true that, once we reach a frame
with its hasCachedSavedFrame bit set, all its parents will have the bit set
as well. However, clear bits under younger set bits will only occur on
Rematerialized frames.
Differential Revision: https://phabricator.services.mozilla.com/D29785
--HG--
extra : moz-landing-system : lando
