CompileInfo::script_ is null for wasm, so avoid calling info.filename()
/ info.line() in that case.
Example backtrace:
js::BaseScript::sourceObject (this=0x0)
js::BaseScript::scriptSource (this=0x0)
js::BaseScript::filename (this=0x0)
js::jit::CompileInfo::filename (this=0x7ffec6422618)
js::jit::DumpMIRExpressions
Differential Revision: https://phabricator.services.mozilla.com/D79698
High-level documentation for how compiler and feature selection are
used to compute compiler and feature availability.
Differential Revision: https://phabricator.services.mozilla.com/D78485
The previous changeset made a change to test262-update.py. This changeset is
the result of running the script, like this:
cd js/src/tests
python test262-update.py --revision 4a8e49b3ca7f9f74a4cafe6621ff9ba548ccc353
The revision is taken from the first line of js/src/tests/test262/GIT-INFO; the
purpose of specifying that revision is to run the script again using the same
input, so that the output reflects only changes to the script itself, not new
tests.
Differential Revision: https://phabricator.services.mozilla.com/D76394
Similar to previous patch, this info is not set on functions with lazy
enclosing functions. Also, inline FunctionBox::setTypeForExposedFunctions
into its only caller.
Differential Revision: https://phabricator.services.mozilla.com/D79283
FieldInitializers is only defined for functions that have a compiled
enclosing script. We should avoid setting the value when it is not defined.
Update initFromLazyFunction so that fieldInitializers are only read for the
function being delazified. Fix XDR to not track fieldInitializers for lazy
functions with lazy parent functions by checking for exisitance of an
enclosingScope.
Also ensure fieldInitializers are set correctly when cloning scripts. In
practice, we delazify entire script tree before cloning but this is a footgun
none the less.
Differential Revision: https://phabricator.services.mozilla.com/D79282
While this is a bit silly, the code does come up in the wild. We avoid
allocating objects for primitives we can can show that the global prototypes
were not tampered with.
Differential Revision: https://phabricator.services.mozilla.com/D78561
After landing a patch to reorganize the directory structure of our irregexp import, one particular testcase (`regexp/huge-02.js`) started failing on Windows 32-bit. It turns out to be a unified build problem: moving around files caused the unified chunks to be allocated slightly differently. After some experimentation, I determined that pulling `regexp-compiler.cc` out of the unified build made the problem go away. It looks like it does not play nicely with `regexp-compiler-tonode.cc`. I don't have easy access to a win32 machine to dig deeper, so I'm landing the easy patch. If there's a real underlying issue, we can fix it when it shows up on a platform that's easier to debug.
Differential Revision: https://phabricator.services.mozilla.com/D79692
The previous changeset made a change to test262-update.py. This changeset is
the result of running the script, like this:
cd js/src/tests
python test262-update.py --revision 4a8e49b3ca7f9f74a4cafe6621ff9ba548ccc353
The revision is taken from the first line of js/src/tests/test262/GIT-INFO; the
purpose of specifying that revision is to run the script again using the same
input, so that the output reflects only changes to the script itself, not new
tests.
Differential Revision: https://phabricator.services.mozilla.com/D76394
In the JIT frame sampler, we apply the appropriate category in addition to
the "implementation" field. For JS frames (IS_JS_FRAME), we identify as
either BaselineInterpreter or Interpreter. Note that JS_Other still applies
to various places we enter SpiderMonkey outside of RunScript.
Differential Revision: https://phabricator.services.mozilla.com/D79524
Replace the duplicate lists in mozglue/baseprofiler/public and js/public with
a shared list. Add this list to both moz.build files so it is published twice
which simplifies supporting different standalone configurations.
Differential Revision: https://phabricator.services.mozilla.com/D79520
The GeneratorInfo data associated with a Debugger.Frame is not guaranteed
to be cleared when a generator transitions from running/suspended to closed.
In the current codebase, we have broadly assumed that to be true, which was
incorrect of us to do.
This patch separates "hasGeneratorInfo" from "isSuspended" so that the two
usecases can be properly separated. This both fixes this bug, and helps make
the codebase clearer about its intent.
Differential Revision: https://phabricator.services.mozilla.com/D79603
Inserts logging (active in DEBUG builds) and adds test cases that check that
the constant folding is triggered in at least trivial cases, cf other
test cases in the same test file.
Differential Revision: https://phabricator.services.mozilla.com/D78928
In general, we should do constant folding as other optimizations may result
in constants to fold. In addition, emcc has been observed not to fold
SIMD constants in all desirable cases.
Differential Revision: https://phabricator.services.mozilla.com/D78899
The changes in xpconnect are necessary because this is not being specified in
the usual way, with a getter. Ordinary data properties require an explicit
loophole to make them visible through X-ray wrappers.
Differential Revision: https://phabricator.services.mozilla.com/D77181
This solves a remaining failure in wasm/spec/spec/left-to-right.wast.js, where
the whole function's body is optimized away.
Differential Revision: https://phabricator.services.mozilla.com/D79439
Using the trapnz instruction was incorrect, because traps can't be resumed in
theory, so the previous x86 backend was only working because it would not
remove the jump after this trap instruction. Make it more correct by not lying
to Cranelift and use a conditional resumable trap instead.
Will need a Cranelift bump as well.
Differential Revision: https://phabricator.services.mozilla.com/D79438
While JS can't observe v128 values, the debugger API can, so
implement a case in ToJSValue for this. Other guards will
ensure that these values (which are somewhat wrong) are not
seen by JS.
Differential Revision: https://phabricator.services.mozilla.com/D79261
I wrote this patch to address two problems:
1. if I do `mach run` from a directory other than $topsrcdir, $objdir, or
$objdir/dist/bin, then .gdbinit will not be loaded.
2. Debugging the firefox binary will never load the JS prettyprinters in any
case.
I believe this patch fixes other problems as well, such as .gdbinit_python not being found, and the gdbpp pretty-printers not getting loaded in various situations.
The main changes of this patch are:
1. Move .gdbinit into build/ (and $objdir/build/) to delay it from getting
loaded until the search path is configured.
2. Move libxul.so-gdb.py into the correct directory.
3. Use either libxul.so-gdb.py or js-gdb.py to configure the correct
search path then load .gdbinit, and have .gdbinit load all of the
pretty-printers (Gecko and JS).
4. Use a single preprocessed file to configure the source directory. Use
relative paths within the objdir for everything else.
Differential Revision: https://phabricator.services.mozilla.com/D77589
I think we were defining those methods in self-hosted JS, because that automatically gives
us the property that they all have the same identity. This causes bad error messages.
Instead redefine them in the finishInit ClassSpec hook. We still have the "wrong" methods
in the 'methods' array so that JSXray tests continue to pass.
Differential Revision: https://phabricator.services.mozilla.com/D79615
This crash happens because we try and clean up the map from target to WeakRef in the WeakRef finalizer, and the target can be dead by this point if it's a nuked CCW (before it is nuked the CCW ensures this sweep order does not happen).
The fix is to fix up the map when CCWs to WeakRefs are nuked. Fortunately there's already a hook where the GC is told about this.
The same issue applies to FinalizationRecordObjects. This fix is slightly different because they don't have a target pointer so we can't find the map entry. Instead we clear the record and cleanup happens later when it gets swept.
Differential Revision: https://phabricator.services.mozilla.com/D79533
The 'asyncStack' flag on JS execution contexts is used as a general switch
to enable async stack capture across all locations in SpiderMonkey, but
this causes problems because it can at times be too much of a performance
burden to general and track all of these stacks.
Since the introduction of this option, we have only enabled it on Nightly
and DevEdition for non-mobile builds, which has left a lot of users unable
to take advantage of this data while debugging.
This patch enables async stack traces across all of Firefox, but introduces
a new pref to toggle the scope of the actual expensive part of async stacks,
which is _capturing_ them and keeping them alive in memory. The new pref
limits the capturing of async stack traces to only debuggees, unless an
explicit pref is flipped to capture async traces for all cases.
This means that while async stacks are technically enabled, and code could
manually capture a stack and pass it back to SpiderMonkey and see that stack
reflected in later captured stacks, SpiderMonkey itself and related async
DOM APIs, among others, will not capture stacks or pass them to SpiderMonkey,
so there should be no general change in performance by enabling the broader
feature itself, unless the user is actively debugging the page.
One effect of this patch is that if you have the debugger open and then close
it, objects that have async stacks associated with them will retain those
stacks and they will continue to show up in stack traces, no _new_ stacks
will be captured. jorendorff and I have decided that this is okay because
the expectation that the debugger fully revert every possible effect that it
could have on a page is a nice goal but not a strict requirement.
Differential Revision: https://phabricator.services.mozilla.com/D68503
Peephole optimizations are not supported by upstream on big endian and deactivated there as well.
Fixes segfault on startup on s390x.
Differential Revision: https://phabricator.services.mozilla.com/D79039
The patch adds areanas allocated during marking into a separate set of arenas lists, which are not swept but are merged back into the main arena lists at the end of sweeping.
We do need to do some sweeping for newly allocated arenas on account of type inference data. I haven't looked too hard into why this is.
Differential Revision: https://phabricator.services.mozilla.com/D79334
Dmitry Bezhetskov
Andy Wingo
Lars T Hansen
Andrew McCreight
Jason Orendorff
Ted Campbell
Tooru Fujisawa
Narcis Beleuzu
Iain Ireland
Logan Smyth
Benjamin Bouvier
Noemi Erli
Steve Fink
Tom Schuster
Jon Coppeard
caroline
M. Sirringhaus
André Bargull
Paul Adenot