Added isHelperThreadContext() to check that cx runs on a helper thread, similar to isMainThreadContext(). Replaced null-checks meant to look for helper threads with isHelperThreadContext(), leaving instances where helperthread() is checked in order to access the actual helper thread.
Differential Revision: https://phabricator.services.mozilla.com/D34937
--HG--
extra : moz-landing-system : lando
When I wrote my prior patch, I forgot that a DebuggerFrame object's
ONSTEP_HANDLER_SLOT holds, not a JavaScript object, but a private value pointing
to an OnStepHandler, which must be explicitly freed.
Differential Revision: https://phabricator.services.mozilla.com/D34978
--HG--
extra : moz-landing-system : lando
Check realm flags at when creating CompileOptions rather than during
compilation. This is helpful for pre-compiling self-hosting code.
Differential Revision: https://phabricator.services.mozilla.com/D34976
--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 NativeIterator objects. I had to store the initial propery count as propertiesEnd can change during the lifetime of this object.
Differential Revision: https://phabricator.services.mozilla.com/D34554
Patch to use std::move when passing AllocPolicy instances to constructors. This also fixes HashTable move constuction/assignment that previously PodAssigned the whole object including the AllocPolicy base.
Differential Revision: https://phabricator.services.mozilla.com/D36175
Nursery objects can have slots buffers in the nursery or in malloc memory; tenured objects always have their slots buffers in malloc memory. When a nursery object has a pointer to a malloced buffer it is present in the Nursery::mallocedBuffers set. The patch checks whether an object is tenured when freeing its slots buffer because if so this tells us that its buffer is malloced and can't be in the nursery's mallocedBuffers set.
This also gets rid of a call to Nursery::isInside() call (linear in the number of nursery chunks) when we know the object is tenured and hence can't reference nursery memory.
Differential Revision: https://phabricator.services.mozilla.com/D36211
The args count needs to be set before the LazyScript takes hold of the
functionbox, or else some code that references lazy functions can get the wrong
number of arguments (ie, CloneFunctionObjectIfNotSingleton on a lazy function)
Differential Revision: https://phabricator.services.mozilla.com/D34586
--HG--
extra : moz-landing-system : lando
In some cases, the nsIScriptError is initialized with zero innerWindowId, but is from chrome context.
For cases, this patch adds an optional aFromChromeContext parameter to nsIScriptError::InitWithWindowID, which default value is false.
Differential Revision: https://phabricator.services.mozilla.com/D34508
--HG--
extra : moz-landing-system : lando
IsMarkingTracer no-longer exists, so remove one comment that refers to it
and fix another comment.
Differential Revision: https://phabricator.services.mozilla.com/D34674
--HG--
extra : moz-landing-system : lando
Member variables `calledPrepareVMCall_` and `inStubFrame_` served the same purpose for their classes.
Unified them in CacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D33526
--HG--
extra : moz-landing-system : lando
Base commit for bug 1467191. Moves declarations of BaselineCacheIRCompiler and IonCacheIRCompiler
into their respective header files.
Differential Revision: https://phabricator.services.mozilla.com/D33521
--HG--
extra : moz-landing-system : lando
Base commit for patch for bug 1467191 that fixes inconsistencies in
namespace use between BaselineCacheIRCompiler and IonCacheIRCompiler.
Differential Revision: https://phabricator.services.mozilla.com/D33516
--HG--
extra : moz-landing-system : lando
Since bug 1535137 the consts array only stores `BigIntValues` so we can change
it to a `BigInt` array. This will also make it easier to fix bug 1535154.
Differential Revision: https://phabricator.services.mozilla.com/D34712
--HG--
extra : moz-landing-system : lando
IsMarkingTracer no-longer exists, so remove one comment that refers to it
and fix another comment.
Differential Revision: https://phabricator.services.mozilla.com/D34674
--HG--
extra : moz-landing-system : lando
We've been relying on frame pointers being indirectly enabled via things
like --enable-profiling for some time, but this doesn't scale because
some things may want frame pointers while wanting --disable-profiling.
So we move MOZ_FRAMEPTR_FLAGS to python configure and add a new option
to decide whether to enable frame pointers or not.
Differential Revision: https://phabricator.services.mozilla.com/D34117
--HG--
extra : moz-landing-system : lando
Use memory tracking APIs to track malloc memory associated with module IndirectBindingMap. These are attached to ModuleObjects and ModuleNamespaceObjects.
Differential Revision: https://phabricator.services.mozilla.com/D34551
Use memory tracking APIs to track malloc memory associated with Shapes. I had to thread FreeOp and BaseShape through in various places so there's enough context.
Differential Revision: https://phabricator.services.mozilla.com/D34377
Use memory tracking APIs to track malloc memory associated with the different ctypes objects.
I ended up creating new public APIs because ctypes currently mostly uses our public APIs, but I actaully don't know why. I don't think it can be built standalone. Maybe this should use the internal APIs instead.
Differential Revision: https://phabricator.services.mozilla.com/D34375
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
Andreea Pavel
Mihai Alexandru Michis
Greg Tatum
Dorel Luca
Kristen Wright
Jim Blandy
Ted Campbell
Jon Coppeard
Ashley Hauck
Paul Bone
André Bargull
Noemi Erli
Jason Orendorff
Tom Ritter
Ross Kirsling
Brian Hackett
arthur.iakab
Razvan Maries
Matthew Gaudet
Eden Chuang
Oana Pop Rus
Adam Holm
Andrea Marchesini
Jan de Mooij
Ehsan Akhgari
Mike Hommey
Ciure Andrei
Bogdan Tara
David Teller
Masatoshi Kimura
Iain Ireland
Gurzau Raul
Brindusan Cristian
Karl Tomlinson
Cosmin Sabou
Yoshi Cheng-Hao Huang
Denis Palmeiro
Jeff Walden
Philip Chimento
Narcis Beleuzu
Tom Schuster
Tarek Ziadé
Benjamin Bouvier
Csoregi Natalia
Nika Layzell
Nicolas B. Pierron
shindli
Gerald Squelart
Sean Stangl
Sebastian Hengst
Steve Fink
Boris Zbarsky
Tooru Fujisawa
Honza Bambas
Julian Seward
Valentin Gosu
Jean-Yves Avenard
Sylvestre Ledru
Kannan Vijayan