Fold the JSScript* and LazyScript* variant arms into a single case. The
debugger now either uses BaseScript accessors directly, or uses
DelazifyScript to ensure bytecode exists if needed.
Note that there are still seperate instances for LazyScript and JSScript so
Debugger::wrapVariantReferent continues to be careful about normalizing
references.
Differential Revision: https://phabricator.services.mozilla.com/D64367
--HG--
extra : moz-landing-system : lando
Add a BaseScript case to variant matcher classes in the debugger and forward
the JSScript and LazyScript cases to it. This will call DelazifyScript for
all cases, so fix a small issue where this failed on non-function scripts.
Subsequent patches will remove the JSScript/LazyScript cases once the variant
type is updated.
Depends on D64365
Differential Revision: https://phabricator.services.mozilla.com/D64366
--HG--
extra : moz-landing-system : lando
The exception is not guaranteed to be in the context compartment anyway (e.g. changing the compartment does not wrap the exception), so there isn't much point checking it up front. And the exception stack is always stored as an unwrapped object, so again there's no point checking it on set, since we just plan to UncheckedUnwrap it.
Differential Revision: https://phabricator.services.mozilla.com/D64004
--HG--
extra : moz-landing-system : lando
We were using `config.status*` as a catchall in `DIST_GARBAGE` for
`config.status` and `config.statusd`. Unfortunately, the latter was a
directory, so `rm config.status*` error'd out. We can fix this easily
by putting `config.statusd` in `GARBAGE_DIRS`, which will use `rm -r`,
as intended.
Differential Revision: https://phabricator.services.mozilla.com/D64422
--HG--
extra : moz-landing-system : lando
Rather than having AutoRunParallelTask call a function that mostly has to interact with GCRuntime, it's more sensible to make this call a GCRuntime method via member function pointer. The syntax is a little gross but this means we can get rid of a few friend declarations that were only necessary to allow these functions access to GCRuntime again.
Differential Revision: https://phabricator.services.mozilla.com/D64147
--HG--
extra : moz-landing-system : lando
This was previously turned from a virtual method into a function pointer because of threading concerns (destroying an instance of a class with virtual methods will write to the vtable before calling superclass destructors which may cause race conditions). However this concern is moot since we made runTask() virtual so that it could be used by XPCOM thread pools. The concern about race conditions is handled by an assertion in the GCParallelTask destructor.
Differential Revision: https://phabricator.services.mozilla.com/D64146
--HG--
extra : moz-landing-system : lando
Once we use BaseScript as the root type, we can combine the ScriptQuery
result vectors which will be concatenated anyways.
Depends on D64124
Differential Revision: https://phabricator.services.mozilla.com/D64125
--HG--
extra : moz-landing-system : lando
This can be combined with the Debugger::scripts map since keys will not
conflict. This is now all possible since we use js::BaseScript as the root
type.
Depends on D64123
Differential Revision: https://phabricator.services.mozilla.com/D64124
--HG--
extra : moz-landing-system : lando
Replace with calls to wrapScript instead. Within wrapScript we now check if
script is lazy or not. This paves way to removing LazyScript* from the
DebuggerReferentVariant.
Depends on D64122
Differential Revision: https://phabricator.services.mozilla.com/D64123
--HG--
extra : moz-landing-system : lando
This lets us eventually combine the lazy and non-lazy lists. To make this
work, we need to explicitly pass the expected type of variant element instead
of deducing it from the map.
Differential Revision: https://phabricator.services.mozilla.com/D64122
--HG--
extra : moz-landing-system : lando
- Simplify js::CheckDebugeeThing
- Simplify DelazifyScript
- Inline js::EnsureFunctionHasScript into callers and avoid using
JSFunction::nonLazyScript() method.
Depends on D64119
Differential Revision: https://phabricator.services.mozilla.com/D64120
--HG--
extra : moz-landing-system : lando
In Bug 1512509 we simplified BaseScript::sourceObject() to never use
cross-compartment edges. As a result we can simplify the debugger access of
sourceObject within this patch.
Differential Revision: https://phabricator.services.mozilla.com/D64119
--HG--
extra : moz-landing-system : lando
This makes sure we will detect use of the contents of moved GC things during the update phase of the GC, not just when we return to the mutator as previously. Annoyingly we need to preserve contents for native objects with fixed elements because the elements flags are stored there and these may be accessed from other objects if they are COW elements.
This caught a use of unforwarded scripts during invalidation caused by OOM during sweeping type information.
Differential Revision: https://phabricator.services.mozilla.com/D63872
--HG--
extra : moz-landing-system : lando
This has just enough code to be able to compile a "return 0;" function,
including off-thread MIR building.
The new builder consists of two parts:
* WarpOracle: runs on the main thread, produces a WarpSnapshot.
* WarpBuilder: can run off-thread, uses the WarpSnapshot to generate MIR.
WarpOracle will make a lot of the optimization decisions (which scripts can be
compiled, which ICs are copied, which functions we want to inline). WarpBuilder
will do 'just' MIR building.
This is an early prototype; the code is expected to change significantly the
coming weeks/months.
Differential Revision: https://phabricator.services.mozilla.com/D64013
--HG--
extra : moz-landing-system : lando
This makes sure we will detect use of the contents of moved GC things during the update phase of the GC, not just when we return to the mutator as previously. Annoyingly we need to preserve contents for native objects with fixed elements because the elements flags are stored there and these may be accessed from other objects if they are COW elements.
This caught a use of unforwarded scripts during invalidation caused by OOM during sweeping type information.
Differential Revision: https://phabricator.services.mozilla.com/D63872
--HG--
extra : moz-landing-system : lando
Uses a reinterpret_cast so we don't need to include `JSFunction.h` in this
header.
Differential Revision: https://phabricator.services.mozilla.com/D64034
--HG--
extra : moz-landing-system : lando
If we try to wrap an inner whose outer has navigated out of process,
then we'll get a remote window proxy, not a window proxy.
This was happening during the JS devtools test
browser_webconsole_block_mixedcontent_securityerrors.js
Differential Revision: https://phabricator.services.mozilla.com/D64217
--HG--
extra : moz-landing-system : lando
We don't need to package tests for builds that we don't actually run
tests from, but it is tricky to align this correctly by setting
MOZ_AUTOMATION_PACKAGE_TESTS=0 in relevant mozconfigs. Instead we can
set the environment variable in the task definition, and use a full
taskgraph verification check to ensure that the flag is only set on
builds that have tests.
The one tricky area is the win64-aarch64 builds, which have a workaround
by specifying the new skip-verify-test-packaging attribute.
In one case, win64-aarch64-shippable has tests that run against it, but
it copies those tests from a win64-aarch64-shippable-no-eme task, which
itself has no tests. Both of those tasks need to skip the verify check
as a result.
In another case, the win64-aarch64-eme task is an artifact build that
grabs test packages from the win64-aarch64 build. Since the win64-aarch64
build doesn't have tests, it needs to skip the verify check.
Differential Revision: https://phabricator.services.mozilla.com/D59426
--HG--
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
Some tests needed to be updated to account for an `Intl` constructor whose
prototype doesn't have a `resolvedOptions` method.
Differential Revision: https://phabricator.services.mozilla.com/D61875
--HG--
extra : moz-landing-system : lando
Canonicalises the `tlang` subtag of a transform extension per the usual rules
for canonicalising the base name parts of a locale identifier. In addition to
that, deprecated `tvalue` subtags are now also replaced with their preferred
replacements according to the `alias` data from CLDR.
Differential Revision: https://phabricator.services.mozilla.com/D61873
--HG--
extra : moz-landing-system : lando
Unicode extension subtags are now canonicalised for all operations, so we no
longer need the UnicodeExtensionCanonicalForm enum.
Unicode extension types provided through option objects are also canonicalised
to ensure no uncanonicalised locales are exposed. This also avoids triggering
various assertions where we assume we only expose fully canonicalised locales.
Also see: https://github.com/tc39/proposal-intl-locale/issues/96
Differential Revision: https://phabricator.services.mozilla.com/D61872
--HG--
extra : moz-landing-system : lando
Variant subtag canonicalisation is back, but with slightly different semantics
compared to IANA BCP 47 canonicalisation.
Differential Revision: https://phabricator.services.mozilla.com/D61871
--HG--
extra : moz-landing-system : lando
Parts 3 and 5 will implement the missing canonicalisation steps for variant
and transform extension subtags.
Differential Revision: https://phabricator.services.mozilla.com/D61870
--HG--
extra : moz-landing-system : lando
Branching on `undefined` in the newly added `ThrowBadDerivedReturnOrUninitializedThis`
function makes it possible to differentiate when `ThrowUninitializedThis()` and when
`ThrowBadDerivedReturn()` needs to be called.
Differential Revision: https://phabricator.services.mozilla.com/D63670
--HG--
extra : moz-landing-system : lando
Only the receiver in a super property access can be a primitive value, the
holder value is guaranteed to be an object, because it's computed from
SuperBase, which always returns an object.
Differential Revision: https://phabricator.services.mozilla.com/D64045
--HG--
extra : moz-landing-system : lando
We don't need to package tests for builds that we don't actually run
tests from, but it is tricky to align this correctly by setting
MOZ_AUTOMATION_PACKAGE_TESTS=0 in relevant mozconfigs. Instead we can
set the environment variable in the task definition, and use a full
taskgraph verification check to ensure that the flag is only set on
builds that have tests.
The one tricky area is the win64-aarch64 builds, which have a workaround
by specifying the new skip-verify-test-packaging attribute.
In one case, win64-aarch64-shippable has tests that run against it, but
it copies those tests from a win64-aarch64-shippable-no-eme task, which
itself has no tests. Both of those tasks need to skip the verify check
as a result.
In another case, the win64-aarch64-eme task is an artifact build that
grabs test packages from the win64-aarch64 build. Since the win64-aarch64
build doesn't have tests, it needs to skip the verify check.
Differential Revision: https://phabricator.services.mozilla.com/D59426
--HG--
extra : moz-landing-system : lando
FinalizationGroups are no longer held live by their targets but are still held live when their cleanup callback is queued. According to the spec implementations are allowed to cancel FinalizationGroup callbacks if the FinalizationGroup dies, but I didn't do that because it adds complexity (we would need the browser to have weak pointers to queued groups).
The patch makes FinalizationRecordObject's FinalizationGroup pointer weak by storing it in a private value and sweeping it as necessary. We need a trace method to update the pointer when it's moved by the GC, but only if traceWeakEdges() is true. We also need a read barrier in case we want to queue cleanup callbacks for an otherwise unreferenced finalization group.
Then this adds a set of all active record objects to the FinalizationGroup objects so we can clear their pointer to group when it dies. We can't do this during sweeping because the group may not be in the same sweep group as the target and so may die earlier or later.
Differential Revision: https://phabricator.services.mozilla.com/D62786
--HG--
extra : moz-landing-system : lando
As a first step to figuring out how to proceed, improve the documentation to show where FinalizationRecordVectorObject is used and to show the types in a couple of places.
Differential Revision: https://phabricator.services.mozilla.com/D62932
--HG--
extra : moz-landing-system : lando
This was always set to false after the StupidAllocator has been removed, so we
could replace it at uses.
Differential Revision: https://phabricator.services.mozilla.com/D63909
--HG--
extra : moz-landing-system : lando
caroline
Ted Campbell
Boris Zbarsky
Nathan Froyd
Steve Fink
Benjamin Bouvier
Jon Coppeard
Jan de Mooij
Brindusan Cristian
André Bargull
Andrew McCreight
Mike Shal
Kris Maglione
Andreea Pavel
Simon Giesecke
Matthew Gaudet