Previously I rolled the malloc byte count into a total byte count for each zone but this may adversely affect GC scheduling (e.g. by triggering more non-incremental GCs because allocation volumes appear higher with this change). So that we can land this machinery without disturbing benchmarks too much, this patch splits out the new malloc memory accounting into a separate counter and uses the maxMallocBytes setting as the threshold (default value is 128MB vs 30MB for the GC heap threshold) and a growth factor of 2. This should make the behaviour closer to the original behaviour for now. We can go back and adjust the parameters later to obtain the desired behaviour.
Differential Revision: https://phabricator.services.mozilla.com/D34181
The change to split out ZoneAllocator messed up the MemoryTracker code that prints out what failed to be removed by making it run after the Zone destructor which will already assert in the case (but without printing useful information first).
Differential Revision: https://phabricator.services.mozilla.com/D33974
Our ultimate goal in this bug is to include information about yields and awaits
in the completion value passed to the `onPop` handler. This means that detecting
when a frame is being suspended becomes just another step in building a
completion value. That change becomes a little clearer if those two steps happen
next to each other.
Differential Revision: https://phabricator.services.mozilla.com/D24996
--HG--
extra : moz-landing-system : lando
When a Debugger.Frame refers to a generator/async call, the generator's script
must be marked as a debuggee, so that if the call is resumed, the
JSOP_AFTERYIELD bytecode is compiled to the instrumentation that re-associates
the extant Debugger.Frame with the new concrete frame.
This extends DebugScript with a new field `generatorObserverCount`, akin to
`stepperCount`, which tracks the number of Debugger.Frames referring to the
script if it is a generator script. This count is adjusted when the
`GeneratorInfo` structure is attached to a `DebuggerFrame`, cleared, and
finalized.
Differential Revision: https://phabricator.services.mozilla.com/D32394
--HG--
extra : moz-landing-system : lando
The new export Pattern.OBJECT_WITH_EXACTLY is like the ordinary Pattern
constructor, but also fails to match if the actual value has any extra
properties.
The default behavior of object matching (to ignore additional properties) is
left unchanged, since there are too many extant tests that rely on this behavior
to be worth fixing.
Differential Revision: https://phabricator.services.mozilla.com/D32880
--HG--
extra : moz-landing-system : lando
A Debugger.Frame for a generator or async call continues to refer to the same
call across suspensions (awaits and yields). This means that, even as the
underlying concrete frames (InterpreterFrame, BaselineFrame) come and go, the
Debugger.Frame retains its relationship with a particular
AbstractGeneratorObject. When that generator is resumed, the Debugger.Frame
acquires the new concrete frame as its new referent.
Normally, when a stack frame is popped, if it had a Debugger.Frame with an
onStep handler, we decrement the frame's script's stepper count, since that
Debugger.Frame's onStep handler is obviously not going to fire any more; the
frame is dead. But in the case of a generator or async frame, the generator call
may be resumed at some point, so for such frames, we leave the script's stepper
count incremented until the generator call returns, throws, or otherwise exits
permanently.
This means that if a Debugger.Frame and its AbstractGeneratorObject are GC'd, we
must decrement the generator's script's stepper count. Of course, the script
itself may also be being GC'd, in which case we need not do anything.
This patch makes DebuggerFrame::clearGenerator solely responsible for dropping
the stepper count on generator frames. Since DebuggerFrame::finalize already
clears the frame's generator, this takes care of the stepper count automatically.
Differential Revision: https://phabricator.services.mozilla.com/D32273
--HG--
extra : moz-landing-system : lando
In later patches in the series, DebuggerFrame needs to be able to access a
generator's script even when the generator object itself is being finalized, so
it's simpler to just hold a reference to it directly.
Differential Revision: https://phabricator.services.mozilla.com/D32272
--HG--
extra : moz-landing-system : lando
Since GetGeneratorObjectForFrame is a bit involved (it looks up the identifier
'.generator' on the scope chain) and not entirely reliable (it returns nullptr
between the GENERATOR and SETALIASEDVAR .generator opcodes), it's better to
simply fetch the generator from the DebuggerFrame, when one is available.
Since a DebuggerFrame has a generator exactly when there is an entry in
generatorFrames going the other direction, from generator to DebuggerFrame, this
means that Debugger::removeFromFrameMapsAndClearBreakpointsIn can actually do
its job reliably, which lets us remove certain kinky conditions in The Famous
Step Count Assertion of 1874.
In other cases, GetGeneratorObjectForFrame is the only option, and its flakiness
doesn't matter; document those a bit better.
Differential Revision: https://phabricator.services.mozilla.com/D32271
--HG--
extra : moz-landing-system : lando
The profiler will require non-fuzzed timers for accuracy. Making the switch early will avoid surprises when FuzzyFox is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D31010
--HG--
extra : moz-landing-system : lando
IsCanonical was only used in StructuredCloneReader::CheckDouble. Two of CheckDouble's three uses already canonicalized the double before checking it, and the third *should* have already done so.
Differential Revision: https://phabricator.services.mozilla.com/D29870
--HG--
extra : moz-landing-system : lando
Back when we first freed the lizard in 1998, it made sense to have copies of NaN/+Inf/-Inf living on the runtime, because Values didn't store doubles inline. That hasn't been true for a long time. This patch gets rid of those.
Differential Revision: https://phabricator.services.mozilla.com/D29868
--HG--
extra : moz-landing-system : lando
We can't generate a constexpr uint64_t containing the bits for positive/negative infinity, because of a (very sensible) static_assert in SpecificNaNBits. This patch adds support to FloatingPoint.h for infinity. The next patch will use it to make JS::InfinityValue constexpr (to match JS::NaNValue).
Differential Revision: https://phabricator.services.mozilla.com/D29869
--HG--
extra : moz-landing-system : lando
1. CanonicalizedDoubleValue should reuse the logic in CanonicalizeNaN.
2. Places that call DoubleValue(CanonicalizeNaN(d)) should just use CanonicalizedDoubleValue(d).
Differential Revision: https://phabricator.services.mozilla.com/D29867
--HG--
extra : moz-landing-system : lando
This is a bit gross, but it passes all the tests that were not already failing.
Differential Revision: https://phabricator.services.mozilla.com/D29057
--HG--
extra : moz-landing-system : lando
We are changing the representation of values on 64-bit. Part 5 of this patch stack has more details on the changes.
Differential Revision: https://phabricator.services.mozilla.com/D29056
--HG--
extra : moz-landing-system : lando
This patch is where the actual changes to our value representation happens. A few notes:
1. We did some weird macro tricks to work around a GCC bug with enums in bitfields. Those bitfields were only useful for poking at values in gdb, and the trick no longer worked with object-biased nanboxing, so I removed it. I also got rid of asDouble_, because it's no longer possible to read the double value right out of the enum without unboxing.
2. In the previous boxing scheme, there was a mechanical conversion between a JSValueType and a JSValueTag. That's no longer true, which is why the big conversion switches exist.
3. Waldo, you were included as a reviewer specifically to look at Value.h and make sure that our gross bit twiddling is just gross and not undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29055
--HG--
extra : moz-landing-system : lando
Similarly to Part 3: when we push a double value, we currently don't distinguish between pushing a boxed double and pushing an unboxed double. This has to change for object-biased NaN-boxing.
Differential Revision: https://phabricator.services.mozilla.com/D29054
--HG--
extra : moz-landing-system : lando
In the past, we have been somewhat sloppy when storing / loading double values, because a boxed double and an unboxed double had the same representation. This is no longer true with object-biased NaN-boxing. This patch goes through and cleans up those cases.
Differential Revision: https://phabricator.services.mozilla.com/D29053
--HG--
extra : moz-landing-system : lando
It took me a while to convince myself that this code was still okay for 0-tagged object Values. Adding a comment to make it clearer for future readers (and in the hope that a reviewer will notice my mistake if I am wrong.)
Differential Revision: https://phabricator.services.mozilla.com/D29052
--HG--
extra : moz-landing-system : lando
Using the old NaN-boxing scheme, a zero-initialized value was a double, which was safe to trace. Under the new scheme, it is a null object pointer.
This patch manually initializes Value arrays to Undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29051
--HG--
extra : moz-landing-system : lando
This is a bit gross, but it passes all the tests that were not already failing.
Differential Revision: https://phabricator.services.mozilla.com/D29057
--HG--
extra : moz-landing-system : lando
We are changing the representation of values on 64-bit. Part 5 of this patch stack has more details on the changes.
Differential Revision: https://phabricator.services.mozilla.com/D29056
--HG--
extra : moz-landing-system : lando
This patch is where the actual changes to our value representation happens. A few notes:
1. We did some weird macro tricks to work around a GCC bug with enums in bitfields. Those bitfields were only useful for poking at values in gdb, and the trick no longer worked with object-biased nanboxing, so I removed it. I also got rid of asDouble_, because it's no longer possible to read the double value right out of the enum without unboxing.
2. In the previous boxing scheme, there was a mechanical conversion between a JSValueType and a JSValueTag. That's no longer true, which is why the big conversion switches exist.
3. Waldo, you were included as a reviewer specifically to look at Value.h and make sure that our gross bit twiddling is just gross and not undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29055
--HG--
extra : moz-landing-system : lando
Similarly to Part 3: when we push a double value, we currently don't distinguish between pushing a boxed double and pushing an unboxed double. This has to change for object-biased NaN-boxing.
Differential Revision: https://phabricator.services.mozilla.com/D29054
--HG--
extra : moz-landing-system : lando
In the past, we have been somewhat sloppy when storing / loading double values, because a boxed double and an unboxed double had the same representation. This is no longer true with object-biased NaN-boxing. This patch goes through and cleans up those cases.
Differential Revision: https://phabricator.services.mozilla.com/D29053
--HG--
extra : moz-landing-system : lando
It took me a while to convince myself that this code was still okay for 0-tagged object Values. Adding a comment to make it clearer for future readers (and in the hope that a reviewer will notice my mistake if I am wrong.)
Differential Revision: https://phabricator.services.mozilla.com/D29052
--HG--
extra : moz-landing-system : lando
Using the old NaN-boxing scheme, a zero-initialized value was a double, which was safe to trace. Under the new scheme, it is a null object pointer.
This patch manually initializes Value arrays to Undefined.
Differential Revision: https://phabricator.services.mozilla.com/D29051
--HG--
extra : moz-landing-system : lando
Stand-alone JS builds now default to without-NSPR on all platforms.
Note that the JS shell builds we do in automation pass --enable-nspr-build so they shouldn't be affected by
the JS shell changes.
Differential Revision: https://phabricator.services.mozilla.com/D33933
--HG--
extra : moz-landing-system : lando
Added thread type as ThreadType enum. Default is ThreadType::THREAD_TYPE_NONE. RunnableTasks must specify their own thread type.
Differential Revision: https://phabricator.services.mozilla.com/D33818
--HG--
extra : moz-landing-system : lando
This is an experiment. We'll see if the fuzzers find anything. If nothing else,
it's good to have the invariants of the ParseNode data structure documented in
code, as assertions, separate from the parser and emitter code.
We can add more checks to this as we go. It may not be fast enough to leave on
in release builds, even in Nightly, and I don't want to push my luck. So
DEBUG-only for now.
Differential Revision: https://phabricator.services.mozilla.com/D32245
--HG--
extra : moz-landing-system : lando
This patch also contains some other cleanups to avoid the need for
special-casing getting symbol IDs at call-sites.
Differential Revision: https://phabricator.services.mozilla.com/D33543
--HG--
extra : moz-landing-system : lando
There is a big difference between generated source files that are built
directly, and those that are only included.
In the latter case, the build system won't know the files that does the
including depends on the generated source. So those sources do need to
be built during the export tier.
But in the former case, the build system has all the dependency
information it needs, and, while these generated sources are currently
built as part of the export tier, they don't actually need to be. We're
going to change that, and in preparation, we rename included files so as
to be more clearly identified.
Differential Revision: https://phabricator.services.mozilla.com/D33770
--HG--
extra : moz-landing-system : lando
The one remaining wart that I'm aware of is that the fallback stub uses ICStubCompilerBase::pushCallArguments, so we'll continue to have two implementations of that code unless/until we overhaul our fallbacks.
Differential Revision: https://phabricator.services.mozilla.com/D33841
--HG--
extra : moz-landing-system : lando
Added mozglue/mozprofiler to js/src/make-source-package.sh, because
mozglue/moz.build will refer to it unconditionally.
Note that if MOZ_GECKO_PROFILER and MOZ_BASE_PROFILER are not defined, no
actual code will be generated.
Differential Revision: https://phabricator.services.mozilla.com/D33789
--HG--
extra : moz-landing-system : lando
We can only reset one slice per GC, as a reset finishes the GC non-incrementally. Change the telemetry to report reset per-GC rather than per-slice as this can suggest the rate of resets is lower than it really is.
Differential Revision: https://phabricator.services.mozilla.com/D33665
I'm not sure how this used to work but I'm pretty sure it doesn't any more. This changes us to use a single defintion of whether we're animating everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D33663
Debugger.Frame objects referring to generator or async calls need to be able to
find the call's generator object, even when the call is suspended. This patch
adds a reserved slot to js::DebuggerFrame objects that points to a new
GeneratorInfo class that holds a cross-compartment wrapper to the generator
object.
Differential Revision: https://phabricator.services.mozilla.com/D32270
--HG--
extra : moz-landing-system : lando
Carrying on from the last patch, there is one place where we use FreeOp unnecessarily when we're not finalizing.
Depends on D33276
Differential Revision: https://phabricator.services.mozilla.com/D33313
--HG--
extra : moz-landing-system : lando
Mutating Debugger state between the time a callback-triggering event is
reported to js::Debugger::onSomeEventSlowPath and the time the
callback is actually called can invalidate assumptions, and multiple Debuggers
are a way to do that, part 183.
Differential Revision: https://phabricator.services.mozilla.com/D32242
--HG--
extra : moz-landing-system : lando
This splits out the allocation functions and allocation tracking state into a new base class, ZoneAllocator, which lives in its own header file. We can include this for the common case of allocating malloc memory for GC things without dragging in the full complexity of Zone.h.
Differential Revision: https://phabricator.services.mozilla.com/D33180
This refactors the malloc allocation tracking so that the MemoryTracker object is only present in debug builds and the count of malloc bytes is kept separately in the Zone. This makes things a little clearer I think and removes one level of inlining.
Differential Revision: https://phabricator.services.mozilla.com/D33179
Previously the end of JumpList's link is marked by `offset + delta == -1`,
BytecodeOffset class introcuced in part 3 requires the operands of `-` operator
should be valid, and that rule conflicts with above.
Changed the end marker of JumpList to `delta == 0`, that won't happen in other
case, because that points the same opcode.
Differential Revision: https://phabricator.services.mozilla.com/D33053
--HG--
extra : moz-landing-system : lando
Previously the initial value of BytecodeSection.lastTarget_ is chosen to make
the following condition true:
lastTargetOffset() + ptrdiff_t(JSOP_JUMPTARGET_LENGTH) == -1
BytecodeOffset class introcuced in part 3 requires the offset value to be
either -1 (invalid) or non-negative, and that rule conflicts with above.
Changed the initial value of BytecodeSection.lastTarget_ to -1 and added
the check for that condition in BytecodeSection::lastOpcodeIsJumpTarget,
so that we don't use negative value in BytecodeOffset.
Differential Revision: https://phabricator.services.mozilla.com/D33052
--HG--
extra : moz-landing-system : lando
Classes defined in JS using the `class` keyword, without using `extends`,
implicitly construct a new `this` object before running the body of the
constructor, and they use `new.target.prototype` as the new object's
[[Prototype]]. This is one of the ways that JS classes support subclassing.
When the subclass calls the base class constructor, the subclass's `.prototype`
is used.
Until now, we did not do this for classes defined in C++ using
JS_NewObjectForConstructor. But there's no reason it shouldn't work the same
way. Changing this is a nicety for embedders -- there's nothing using it in
Firefox or internally right now, except for testing.
Differential Revision: https://phabricator.services.mozilla.com/D31490
--HG--
extra : moz-landing-system : lando
globalThis was already handled specially in JS_ResolveStandardClass,
JS_MayResolveStandardClass, and various other places, but not in
JS_NewEnumerateStandardClasses.
Differential Revision: https://phabricator.services.mozilla.com/D32045
--HG--
extra : moz-landing-system : lando
This field of js::DebugScript is a count of the number of Debugger.Frames with
onPop handlers that apply to the given script, and its name should reflect that
more directly. All accessors and mutators renamed accordingly.
Differential Revision: https://phabricator.services.mozilla.com/D32269
--HG--
extra : moz-landing-system : lando
The present JSScript::setNewStepMode method deals with both increments and
decrements. This provides a single site from which to call
BaselineScript::toggleDebugTraps. But it also checks whether it should free the
DebugScript, which is only needed when we're decrementing, and requires
incrementStepModeCount to furnish a FreeOp which is never needed.
On the balance, removing setNewStepMode altogether and letting
JSScript::incrementStepModeCount and decrementStepModeCount each specialize in
building things up or tearing things down seems cleaner, even if both need to
call toggleDebugTraps.
Differential Revision: https://phabricator.services.mozilla.com/D32268
--HG--
extra : moz-landing-system : lando
- DISABLE_SHARED_JS and DISABLE_EXPORT_JS have been deprecated for 3
years,
- MOZ_JEMALLOC4 has been deprecated for 2 years.
Differential Revision: https://phabricator.services.mozilla.com/D32928
--HG--
extra : moz-landing-system : lando
All extant calls to JSScript::ensureDebugScript are immediately followed by a
call to JSScript::debugScript. A fallible getOrCreate interface is cleaner for
the callers, and not much more work in the callee.
Differential Revision: https://phabricator.services.mozilla.com/D32267
--HG--
extra : moz-landing-system : lando
Giving DebugScript a `needed` method makes the tests for cleaning it up a little
neater, and will help us add more doodads to it in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D32266
--HG--
extra : moz-landing-system : lando
Wasm globals that are mutable and either imported or exported are, in our
implementation, accessed through a level of indirection. The instance's global
area doesn't hold the value itself. Instead it holds an immutable pointer to
the location where the value is really stored.
CL doesn't know that the pointer is immutable, and so fails to CSE/GVN
together multiple reads of the pointer, even when it's obvious it would be
safe to do so. This patch marks it as `readonly` so that such commoning
up can happen.
Differential Revision: https://phabricator.services.mozilla.com/D33007
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
The option has presumably not worked for at least a year, and was seldom
used.
Differential Revision: https://phabricator.services.mozilla.com/D32418
--HG--
extra : moz-landing-system : lando
We do this because we will be introducing more privileged content processes
and we want to be able to distinguish them.
Differential Revision: https://phabricator.services.mozilla.com/D30274
--HG--
rename : browser/base/content/test/tabs/browser_new_tab_in_privileged_process_pref.js => browser/base/content/test/tabs/browser_new_tab_in_privilegedabout_process_pref.js
extra : moz-landing-system : lando
This adds memory tracking for object elements. I had to swap the association in JSObject::swap. I also moved NativeObject::shrinkCapacityToInitializedLength out of line so as not to have to pull Zone.h into NativeObject.h. I don't know how performance sensitive this is - if it is I could look at this again.
Differential Revision: https://phabricator.services.mozilla.com/D32171
The option has presumably not worked for at least a year, and was seldom
used.
Differential Revision: https://phabricator.services.mozilla.com/D32418
--HG--
extra : moz-landing-system : lando
The option has presumably not worked for at least a year, and was seldom
used.
Differential Revision: https://phabricator.services.mozilla.com/D32418
--HG--
extra : moz-landing-system : lando
TenuringTracer::traverse(JSObject**) and
TenuringTracer::traverse(JSString**) will check IsInsideNursery(),
and also these two functions will be called by other callers,
so removing the check in CellPtrEdge::traceTyped
Differential Revision: https://phabricator.services.mozilla.com/D32167
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
To extract Huffman tables (see bug 1552435), we need the ability to walk through the grammar.
This patch starts implementing grammar walking, as macros - at this stage, sufficiently to walk
through interfaces and start dealing with their fields.
Depends on D32291
Differential Revision: https://phabricator.services.mozilla.com/D32295
--HG--
extra : moz-landing-system : lando
To extract Huffman tables (see bug 1552435), we need the ability to walk through the grammar.
This patch starts implementing grammar walking, as macros - at this stage, sufficiently to walk
through interfaces and start dealing with their fields.
Depends on D32291
Differential Revision: https://phabricator.services.mozilla.com/D32295
--HG--
extra : moz-landing-system : lando
This patch changes Wasm-via-CL to always use a 32-bit comparison for interrupt checks.
Wasm-via-Cranelift generates code to do interrupt checks by doing a
machine-word sized comparison. However, the compared-against value,
TlsData::interrupt, is an Atomic<uint32_t, mozilla::Relaxed>, and so the
comparison is incorrect on all 64 bit targets: it also compares the 4 bytes
following TlsData::interrupt, which look to me as if they are an alignment
hole (iow, junk).
This is obviously incorrect, and it's observably inconsistent with what the
-via-Ion and -baseline routes do, which is to always generate a 32-bit
comparison.
It also holds a potential danger of a store-forwarding stall (big read after
small write), although, based on the struct layout and detailed reading of the
Intel opt guide, I think it's probably harmless for the Intel Core
architecture family.
Differential Revision: https://phabricator.services.mozilla.com/D32421
--HG--
extra : moz-landing-system : lando
JitScript::initICEntriesAndBytecodeTypeMap is still in BaselineIC.cpp because
it depends on things defined there (like FallbackStubAllocator) and I think it's
not unreasonable to keep it there.
Differential Revision: https://phabricator.services.mozilla.com/D32303
--HG--
extra : moz-landing-system : lando
We now do a single pass over the bytecode instead of two.
Register pressure of the combined code might be a bit worse but it also
eliminates some duplication so I think it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D32298
--HG--
extra : moz-landing-system : lando
To extract Huffman tables (see bug 1552435), we need the ability to walk through the grammar.
This patch starts implementing grammar walking, as macros - at this stage, sufficiently to walk
through interfaces and start dealing with their fields.
Depends on D32291
Differential Revision: https://phabricator.services.mozilla.com/D32295
--HG--
extra : moz-landing-system : lando
"Discard" instead of "Release" for consistency with ShouldDiscardBaselineCode.
Differential Revision: https://phabricator.services.mozilla.com/D32294
--HG--
extra : moz-landing-system : lando
The destroy() call in JSScript::finalize was moved into DestroyJitScripts for
consistency with BaselineScript and IonScript.
Differential Revision: https://phabricator.services.mozilla.com/D32290
--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 structured spewer does not exit gracefully when the browser is closed. This leads to incomplete JSON since we never end up emitting the closing ']' on destruction. Another approach that lets us do this gracefully is to have the structured spewer start and stop alongside the gecko profiler. This also lets us focus spewing on the specific area of interest such as a page load, or some janky behaviour on a website.
Differential Revision: https://phabricator.services.mozilla.com/D32135
--HG--
extra : moz-landing-system : lando
This changes ZoneAllocPolicy to use the new precise memory tracking rather than the old malloc counter. This works because the mozilla standard containers (HashMap, Vector, etc) already call the AllocyPolicy free_ method with the correct size. This patch tracks individual instances of ZoneAllocPolicy to check that the numbers balance.
Differential Revision: https://phabricator.services.mozilla.com/D33001
There are a couple of places where this method is just used to check the thresholds so I made the size parameter default to zero. Perhaps we should make this a separate trigger.
This also adds a separate GC reason for incremental slices trigger from this method so we can distinguish incremental and non-incremental triggers.
Differential Revision: https://phabricator.services.mozilla.com/D33000
This method was a bit of a footgun because cx->currentScript is quite slow.
It seems better to make this very explicit in the callers.
Differential Revision: https://phabricator.services.mozilla.com/D31611
--HG--
extra : moz-landing-system : lando
The "stubs used in compound opcodes" comment is obsolete (refered to some old
opcodes and JaegerMonkey).
This caught one problem, the interpreter called this for JSOP_RESUME.
Differential Revision: https://phabricator.services.mozilla.com/D31608
--HG--
extra : moz-landing-system : lando
SetThis -> MonitorThisType
SetArgument -> MonitorArgType
Monitor -> MonitorBytecodeType
This is consistent with the thisTypes/argTypes/bytecodeTypes accessors and will
avoid confusion when we rename TypeScript to JitScript.
Differential Revision: https://phabricator.services.mozilla.com/D31607
--HG--
extra : moz-landing-system : lando
It makes the code a bit more natural.
The patch also changes these methods to take an AutoSweepTypeScript. This is more
correct and safe than what we did, because these methods return the TypeSet.
Differential Revision: https://phabricator.services.mozilla.com/D31606
--HG--
extra : moz-landing-system : lando
These have been unnecessary since the ICScript introduction: when performing the
arguments analysis we have a JitScript but not a BaselineScript.
Depends on D32103
Differential Revision: https://phabricator.services.mozilla.com/D32126
--HG--
extra : moz-landing-system : lando
ICScript and JitScript had the same lifetime already, but this eliminates
a malloc/free and some extra dereferences (especially for accessing ICEntries
from Baseline Interpreter code).
This is just the minimal set of changes to make it easier to review. Follow-up
changes should:
* Move (now) JitScript methods to JitScript.cpp
* Merge FillBytecodeTypeMap with JitScript::initICEntries so we do just a single
bytecode walk.
* Move JitScript from the js namespace to js::jit.
Differential Revision: https://phabricator.services.mozilla.com/D32103
--HG--
extra : moz-landing-system : lando
Some of the TypeInference-related static methods were kept in TypeInference-inl.h and
TypeInference.cpp because of various dependencies. Also, methods like JitScript::MonitorAssign
probably don't belong on JitScript anyway, but for now this seems reasonable.
Differential Revision: https://phabricator.services.mozilla.com/D31982
--HG--
rename : js/src/vm/TypeInference-inl.h => js/src/jit/JitScript-inl.h
rename : js/src/vm/TypeInference.cpp => js/src/jit/JitScript.cpp
rename : js/src/vm/TypeInference.h => js/src/jit/JitScript.h
extra : moz-landing-system : lando
Also JSScript::makeTypes => JSScript::createJitScript for consistency with code
elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D31755
--HG--
extra : moz-landing-system : lando
The new trace logger spew routines do not have a corresponding empty inline version for when --disable-trace-logging is used.
Differential Revision: https://phabricator.services.mozilla.com/D32156
--HG--
extra : moz-landing-system : lando
And with some tidying some comments and removing stray #include "gfxPrefs.h"
Differential Revision: https://phabricator.services.mozilla.com/D31468
--HG--
extra : moz-landing-system : lando
Add Jitspewing control for tracelogger data. This can be enabled from the profiler or from the JS shell. Usage is as follows:
From browser (ION_SPEW_FILENAME is recommended here so stdout doesn't get clobbered by each process):
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger ION_SPEW_FILENAME=tracelogger ./mach run
2. Enable JSTracer feature in profiler addon
3. Start profiling and ctrl+shift+2 to view profile, and the data will be automatically spewed during profile collection.
From shell:
1. JS_TRACE_LOGGING=1 IONFLAGS=tracelogger dist/bin/js test.js
2. Data is automatically spewed to stdout when the shell exits, or use ION_SPEW_FILENAME.
There is an optional environment variable JS_TRACELOGGER_SPEW that can be used to emit specific events, for example JS_TRACELOGGER_SPEW="Interpreter,Baseline,GC" will emit only those specific events along with the script and self time of each script.
The structured spewer is also supported with SPEW=tracelogger, and this will emit the tracelogger data for every recorded event.
Differential Revision: https://phabricator.services.mozilla.com/D30033
--HG--
extra : moz-landing-system : lando
These calls were changed from wrap() to rewrap() in bug 1291001.
Also, fix a minor typo in xpcprivate.h, because I didn't feel like
filing a separate bug for it.
Differential Revision: https://phabricator.services.mozilla.com/D31688
--HG--
extra : moz-landing-system : lando
Add a special path for the external read barrier API where we inline most of the checks and then always perform the barrier if we call into the engine. This also skips dispatching on trace kind since we know the barrier tracer is always a GCMarker.
This is kind of hacky and I'm not sure how much it gains us (it's difficult to tell in profiles where GC may occur at different times). What do you think?
Differential Revision: https://phabricator.services.mozilla.com/D31803
--HG--
extra : moz-landing-system : lando
Since we now have precise memory accounting for externally allocated memory associated with GC things we should be able to remove use of the existing malloc counter here. This should help with cases where we trigger too many GCs because we think there is more memory associated than there really is.
Differential Revision: https://phabricator.services.mozilla.com/D31806
--HG--
extra : moz-landing-system : lando
This changes the format of the trace list from using -1 as a delimter to storing the list lengths up front so that we have length information.
Differential Revision: https://phabricator.services.mozilla.com/D34731
Note that we only track the for typed arrays that are not backed by an ArrayBuffer as the memory is tracked there from then on.
Differential Revision: https://phabricator.services.mozilla.com/D34729
I had to store the length as the first word of the bytecode. I also shuffled RegExpShared fields around to make the class a little smaller.
Differential Revision: https://phabricator.services.mozilla.com/D34726
Some kinds of memory use (e.g. reg exp byte code) require multiple memory associations for a single cell. This patch adds machinery to let that happen for specific uses.
Differential Revision: https://phabricator.services.mozilla.com/D34723
I wanted to make VectorMatchPairs use ZoneAllocPolicy but this is also used in a bunch of places where it's not attached to a GC thing, so I left this as a todo.
Differential Revision: https://phabricator.services.mozilla.com/D34556
Use memory tracking APIs to track malloc memory associated with ArgumentsObjects. This one is slightly more complicated because we can allocate these in the nursery and malloc memory is not tracked for nursery objects, so we have to do this if they get tenured.
Differential Revision: https://phabricator.services.mozilla.com/D34553
Use memory tracking APIs to track malloc memory associated with IonScripts and BaselineScripts. This does the memory accounting when they are attached/detached from the JSScript rather than on initialisation/finalization as normally. I had to record the allocation size in the objects themselves. Hopefully this isOK.
Differential Revision: https://phabricator.services.mozilla.com/D34552
This simplifies the code a bit because ElementAccessHasExtraIndexedProperty
checks for length-overflow and sparse-indexes so the callers don't have to
do that anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29486
--HG--
extra : moz-landing-system : lando
Added mozglue/mozprofiler to js/src/make-source-package.sh, because
mozglue/moz.build will refer to it unconditionally.
Note that if MOZ_GECKO_PROFILER and MOZ_BASE_PROFILER are not defined, no
actual code will be generated.
Differential Revision: https://phabricator.services.mozilla.com/D33789
--HG--
extra : moz-landing-system : lando
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
Also rename decommitAllArenasWithoutUnlocking to make it clear that it does
not do what decommitAllArenas does, since it only decommits free arenas.
Differential Revision: https://phabricator.services.mozilla.com/D33108
--HG--
extra : moz-landing-system : lando
This has a few benefits:
* Less toggling when we discard/reallocate the BaselineScript without discarding
the JitScript.
* Wasm's JIT exit optimization will work with the Baseline Interpreter in the
future.
* The next part will use this to eliminate a load.
Differential Revision: https://phabricator.services.mozilla.com/D32444
--HG--
extra : moz-landing-system : lando
The lazy link stub used to assume a JIT caller but this is no longer the case.
We can then fold clearDependentWasmImports into unlinkDependentWasmImports.
Differential Revision: https://phabricator.services.mozilla.com/D32442
--HG--
extra : moz-landing-system : lando
This removes a word from JSScript and corresponding Wasm data structures.
Furthermore, the skip-argument-type-checks optimization depends on JitScript's
lifetime so moving it to JitScript feels right and might help catch bugs.
Differential Revision: https://phabricator.services.mozilla.com/D32441
--HG--
extra : moz-landing-system : lando
This code is debug-only, but it seems a shame to waste have this key structure take up two words when it will fix into one. This also moves the MemoryUse enum definition to gc/GCEnum.h.
Differential Revision: https://phabricator.services.mozilla.com/D32170
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
This replaces the various Debugger-related member classes in
js::CrossCompartmentKey with a series of small structs that can be used directly
as alternatives in CrossCompartmentKey::WrappedType. Thus, instead of having a
two-level tag --- the Variant tag, and then for DebuggerAndObject case, a
DebuggerObjectKind value --- the Variant tag can do all the work by itself.
This also tightens up the types a bit: choosing the wrong DebuggerObjectKind
would be a silent error, but using the wrong constructor might get you a type
error (although unfortunately some of the types are not as specific as you might
hope: NativeObject instead of WasmInstanceObject, for example).
A new comment explains the rationale for giving Debugger API objects entries in
the wrapper map.
Differential Revision: https://phabricator.services.mozilla.com/D28781
--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
David Teller
Jon Coppeard
Karl Tomlinson
Cosmin Sabou
Brindusan Cristian
Yoshi Cheng-Hao Huang
Noemi Erli
Jim Blandy
Denis Palmeiro
Jeff Walden
Iain Ireland
Philip Chimento
Jan de Mooij
Narcis Beleuzu
Andreea Pavel
Kristen Wright
Jason Orendorff
Tom Schuster
Tarek Ziadé
Benjamin Bouvier
Csoregi Natalia
Nika Layzell
Nicolas B. Pierron
shindli
Mike Hommey
Paul Bone
Gerald Squelart
arthur.iakab
Sean Stangl
Sebastian Hengst
Steve Fink
Boris Zbarsky
Bogdan Tara
Ashley Hauck
Tooru Fujisawa
Ehsan Akhgari
Matthew Gaudet
Honza Bambas
Julian Seward
Tom Ritter
Oana Pop Rus
Valentin Gosu
Gurzau Raul
Jean-Yves Avenard
Sylvestre Ledru
Kannan Vijayan
Daniel Varga
Razvan Maries
Andrew McCreight
Edgar Chen
Dorel Luca
Brian Hackett
Brendan Dahl
Luke Wagner
Coroiu Cristina
Ciure Andrei
thomasmo
Kagami Sascha Rosylight
Jonas Allmann
Andy Wingo
Ryan VanderMeulen
Mihai Alexandru Michis
Geoff Brown