This patch adds telemetry to measure the time spent in Wasm compilers
and in the code that they generate (actually, all JS and Wasm code).
For simplicity, it measures wallclock time as a proxy for CPU time.
Furthermore, it measures runtime for all JS and Wasm code, and all
native functions invoked by the JS or Wasm code, by timing from
top-level entry to exit. This is for efficiency reasons: we do not want
to add a VM call in the transition stubs between native and JS or JS and
Wasm; that would be a Very Bad Thing for performance, even for a Nightly
build instrumented with telemetry. Because of that, it's difficult to
separate JITted JS and JITted Wasm runtime, but observing their sum
should still be useful when making comparisons across compiler changes
because absolute reductions will still be visible.
The plumbing is somewhat awkward, given that Wasm compilers can run on
background threads. It appears that the telemetry-callback API that
SpiderMonkey includes to avoid a direct dependency on the Gecko
embedding had artificially limited the callback to main-thread use only.
This patch removes that limitation, which is safe at least for Gecko;
the telemetry hooks in Gecko are thread-safe (they take a global mutex).
That way, the background threads performing compilation can directly add
telemetry incrementally, without having to pass this up through the main
thread somehow.
Finally, I have chosen to add the relevant metrics as Scalar telemetry
values rather than Histograms. This is because what we are really
interested in is the sum of all these values (all CPU time spent in
compilation + running Wasm code); if this value goes down as a result of
a Wasm compiler change, then that Wasm compiler change is good because
it reduces CPU time on the user's machine. It is difficult to add two
Histograms together because the bins may have different boundaries. If
we instead need to use a binned histogram for other reasons, then we
could simply report the sum (of all compiler time plus run time) as
another histogram.
Differential Revision: https://phabricator.services.mozilla.com/D85654
This patch adds telemetry to measure the time spent in Wasm compilers
and in the code that they generate (actually, all JS and Wasm code).
For simplicity, it measures wallclock time as a proxy for CPU time.
Furthermore, it measures runtime for all JS and Wasm code, and all
native functions invoked by the JS or Wasm code, by timing from
top-level entry to exit. This is for efficiency reasons: we do not want
to add a VM call in the transition stubs between native and JS or JS and
Wasm; that would be a Very Bad Thing for performance, even for a Nightly
build instrumented with telemetry. Because of that, it's difficult to
separate JITted JS and JITted Wasm runtime, but observing their sum
should still be useful when making comparisons across compiler changes
because absolute reductions will still be visible.
The plumbing is somewhat awkward, given that Wasm compilers can run on
background threads. It appears that the telemetry-callback API that
SpiderMonkey includes to avoid a direct dependency on the Gecko
embedding had artificially limited the callback to main-thread use only.
This patch removes that limitation, which is safe at least for Gecko;
the telemetry hooks in Gecko are thread-safe (they take a global mutex).
That way, the background threads performing compilation can directly add
telemetry incrementally, without having to pass this up through the main
thread somehow.
Finally, I have chosen to add the relevant metrics as Scalar telemetry
values rather than Histograms. This is because what we are really
interested in is the sum of all these values (all CPU time spent in
compilation + running Wasm code); if this value goes down as a result of
a Wasm compiler change, then that Wasm compiler change is good because
it reduces CPU time on the user's machine. It is difficult to add two
Histograms together because the bins may have different boundaries. If
we instead need to use a binned histogram for other reasons, then we
could simply report the sum (of all compiler time plus run time) as
another histogram.
Differential Revision: https://phabricator.services.mozilla.com/D85654
All the supported compilers support a GNU AS-like syntax, with only a
few details varying. It means we can use a single, simpler, way to
include the ICU data file, instead of 3 different ways, including one
that uses armasm64.exe, possibly wrapped with Wine.
Differential Revision: https://phabricator.services.mozilla.com/D82144
This commit enable reference-types by default. The existing config/ifdef'ery is
spared to allow for an easier backout and to support Cranelift until it gains
support for the feature.
Depends on D81012
Differential Revision: https://phabricator.services.mozilla.com/D81013
This commit enables the bulk-memory-operations feature by default. The config/
ifdef'ery is spared to allow for easier backouts if needed.
Differential Revision: https://phabricator.services.mozilla.com/D81012
This patch generalizes the x64 code that was moved into x86-shared
code in the previous patch, and makes it all work for x86.
Generally the changes are pedestrian. The most interesting bit is
that signed right shift i64x2 is now scalarized in the compilers, not
in the macroassemblers, as this simplifies code everywhere. This
gives rise to a new kind of porting API that reveals information about
what the macroassembler supports on the platform, in the form of the
MustScalarize/MustMaskShiftCount predicates in MacroAssembler.h.
Multiply i64x2, which is scalarized in the macroassemblers now, could
have been subjected to the same treatment, but I did not do so (yet)
because this op presented fewer problems than the right shift. (Discuss.)
Differential Revision: https://phabricator.services.mozilla.com/D74935
I kept a running list of code that would be dead once we removed the old engine. This is what was on that list.
Note: The regexp_parse tests used a testing function that parsed a regexp and returned an AST to compare against the expected AST. They are being deleted because the tests are fragile in the face of upstream changes, not particularly useful, and a lot of work to convert.
Depends on D77727
Differential Revision: https://phabricator.services.mozilla.com/D77728
Currently our wasm-gc prototypes requires that typed objects are enabled,
and of course it is also dependent on reference types. So make sure the
default is computed correctly and die during configure if wasm-gc is
requested while the other options are disabled.
Differential Revision: https://phabricator.services.mozilla.com/D77780
At the same time, because it's now simpler to do so, set the right data
file name for big-endians, even though we don't have or produce it
(bug #1264836). Also remove USE_ICU, which is redundant with
JS_HAS_INTL_API, and actively break the build at configure time when
using --without-intl-api with Firefox because this hasn't actually
worked for close to 3 years (since bug 1402048).
Differential Revision: https://phabricator.services.mozilla.com/D77416
Versions of NSPR >= 4.10 come with a pkg-config file. We currently
depend on 4.9.2 for spidermonkey, but much more recent versions for
Firefox. 4.10 is less than a year newer than 4.9.2, and 4.10 is 7 years
old, so bumping the requirement to 4.10 is not really a big deal.
With the use of pkg-config, --with-nspr-cflags and --with-nspr-libs are
not needed.
None of the AC_TRY_COMPILE tests were any useful because
PR_STATIC_ASSERT and PR_UINT64 have been when we look for them since
4.8.6 and 4.9 respectively.
Differential Revision: https://phabricator.services.mozilla.com/D77412
Change --wasm-simd to --no-wasm-simd and flip the default for both this
switch and for the about:config flag.
Add testing directives so that we test baseline, ion, and --no-wasm-simd.
Differential Revision: https://phabricator.services.mozilla.com/D71819
This patch removes the compile-time and run-time flags that disable BigInt/I64 so that the feature can be shipped. It also adjusts/removes tests as appropriate to account for the removed code paths.
Differential Revision: https://phabricator.services.mozilla.com/D74142
The tracing framework is unused but Matthew found the hook points useful, so this changes those into empty inline functions that can be used to insert probes.
Differential Revision: https://phabricator.services.mozilla.com/D73816
We add a configuration option for SIMD and apply ENABLE_WASM_SIMD
throughout the engine as appropriate, mostly to insert #error or
MOZ_CRASH where things need to be done in later patches or for
architectures that we won't currently consider.
We add a command line switch for the shell and an option for
about:config and plumb the value of this through the engine.
Differential Revision: https://phabricator.services.mozilla.com/D57940
For many years now this has covered all our JIT codegen, not just Ion, so this is
a lot less confusing. Using --enable-ion/--disable-ion now results in an error that
suggests the new name.
Differential Revision: https://phabricator.services.mozilla.com/D69579
--HG--
extra : moz-landing-system : lando
These days we can get the same information by checking JS_CODEGEN_NONE, so let's
do that.
Differential Revision: https://phabricator.services.mozilla.com/D69578
--HG--
extra : moz-landing-system : lando
Now that multi-value is code-complete, we enable it on nightly browsers
in addition to shell builds.
Differential Revision: https://phabricator.services.mozilla.com/D68791
--HG--
extra : moz-landing-system : lando
Kannan Vijayan
Cosmin Sabou
Lars T Hansen
Ricky Stewart
Chris Fallin
Butkovits Atila
Ryan Hunt
Mike Hommey
Ted Campbell
Csoregi Natalia
Razvan Maries
Iain Ireland
Bogdan Tara
Asumu Takikawa
Sebastian Hengst
Narcis Beleuzu
Andy Wingo
Jon Coppeard
Jan de Mooij
Dorel Luca