This affects the following platforms:
* x64: use a RIP-relative LEA instead of an immediate MOV. This saves a few
hundred bytes total and seems to be a little bit faster on interpreter
micro-benchmarks.
* arm64: use ADR instead of LDR. Seems to be a measurable speedup running
Speedometer on Pixel 2 with the JITs disabled.
Differential Revision: https://phabricator.services.mozilla.com/D43398
--HG--
extra : moz-landing-system : lando
The closedOverBinding set uses the SystemAllocPolicy so we must manually
raise OOM exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D43650
--HG--
extra : moz-landing-system : lando
We only recurse into js/src/rust when jsrust is built, which it may not
be in Gecko builds. But cranelift, which may be enabled either way,
needs the extra-bindgen-flags file.
Differential Revision: https://phabricator.services.mozilla.com/D43699
--HG--
extra : moz-landing-system : lando
The closedOverBinding set uses the SystemAllocPolicy so we must manually
raise OOM exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D43650
--HG--
extra : moz-landing-system : lando
Pages that use 'new Function' heavily create a lot of ScriptSource
objects and waste memory duplicating filenames. This is particularly
problematic if the filename is a data-url. Use the existing runtime
strings cache as a straightforward way to share this. The source text
already is using this cache.
For the XDR case, we expect filenames to almost always be unique so we
can eagerly allocate the owned strings without worrying.
Differential Revision: https://phabricator.services.mozilla.com/D43186
--HG--
extra : moz-landing-system : lando
Add accessors to avoid direct access to fields so storage can be changed
later.
Differential Revision: https://phabricator.services.mozilla.com/D43185
--HG--
extra : moz-landing-system : lando
Use accessors instead of directly accessing fields so that we can later
do automatic deduplication. Add setters that can be passed owned strings
when they are available.
Replace the XDRState::codeCString mechanism entirely. First restrict
string lengths to JSString::MAX_LENGTH as a reasonable upper bound.
Introduce XDRState::codeCharsZ to generate owned strings while decoding.
In practice we would duplicate the string anyways and this better
supports unaligned and endian-safe char16_t strings as well.
Together we do the same number of copies as before.
Differential Revision: https://phabricator.services.mozilla.com/D43184
--HG--
extra : moz-landing-system : lando
For starters, js tests require the js shell, so recursing js/src/tests
make no sense.
As for the other, it feels like it's reasonably that if one didn't
opt-in to build the js shell for Gecko builds, they are not interested
in jsapi-tests and gdb-tests either.
The default for Spidermonkey standalone build being to build the shell,
nothing changes for them.
Building jsapi-tests and gdb-tests forces to build jsrust, which can be
a drag when building Firefox.
Differential Revision: https://phabricator.services.mozilla.com/D43537
--HG--
extra : moz-landing-system : lando
Maybe back when .cargo/config.in was added, the directory indicated for
vendored crates needed to be absolute. That is at least not the case
with the current supported versions of rust.
The current setup has a few caveats:
- .cargo/config.in has shown to become stale (it currently contains
multiple unused entries)
- non-gecko build tasks have to generate a .cargo/config on their own if
they want to use vendored crates
- in turn, non-gecko build tasks that don't, may unknowingly get their
dependencies from crates.io (see the recent attempt at moving
geckodriver builds to a separate task).
By checking in a .cargo/config file, we can alleviate the last two, but
that comes at the price of `cargo update` not wanting to act when
.cargo/config exists, because of the source replacement configuration.
But rust vendor gently generates a suitable configuration on its own, so
we can use that to generate a .cargo/config automatically. Which
addresses the first caveat of the current setup. That leaves us with
`cargo update` not working out of the box, but that just requires people
running it to manually remove .cargo/config first. Which is arguably
what rust wants you to do in the first place. It's kind of incidental
that we started with a .cargo/config.in rather than .cargo/config.
Now, while a simple .cargo/config works, that's not enough for the case
where the objdir doesn't live inside the source directory. In that case
cargo looks for the configuration from the objdir, and fails to find it.
So we still need a .cargo/config.in, which we generate with a little
trick.
Differential Revision: https://phabricator.services.mozilla.com/D43012
--HG--
rename : .cargo/config.in => .cargo/config
extra : moz-landing-system : lando
Bug 1454613 enabled binast (binsource back then) so that automation
would catch trivial build errors. The caveat is that it incurs build
times for everyone, while the tool is not even used during the build:
the result of running it is checked into the tree.
Ideally, it would be built in entirely separate tasks, but the overhead
of setting up a task (checking out the repository, downloading
toolchains, etc.) is actually large enough that it's overkill to build
completely separately.
However, it makes sense to limit to spidermonkey standalone builds.
Differential Revision: https://phabricator.services.mozilla.com/D43208
--HG--
extra : moz-landing-system : lando
At some point we can think about triggering incremental slices here the way we do for the GC heap allocations but for now it's simplest to just not trigger any more slices if we're already allocating.
Differential Revision: https://phabricator.services.mozilla.com/D43099
--HG--
extra : moz-landing-system : lando
I missed changing this when I changed the threshold to be the incremental trigger rather than the non-incremental one. I'm not entirely sure we need this chech at all - I think it will only happen in the case where we've requested a non-incremental GC but the interrupt hasn't caused one to run yet.
Differential Revision: https://phabricator.services.mozilla.com/D43035
--HG--
extra : moz-landing-system : lando
This was already transferring ownership to caller so use appropriate
types instead.
Depends on D43182
Differential Revision: https://phabricator.services.mozilla.com/D43183
--HG--
extra : moz-landing-system : lando
Based on discussions with :djvj, it seems that this IC attachment logic is
overly conservative. We're seeing a case where the `__proto__` of a constructor
function is reassigned, which causes all instanceof ICs to fail to attach. The
test case is like:
function C() { /* ... */ }
C.__proto__ = D;
var o = new C();
var result = o instanceof C; // this IC fails to attach
This change generalizes the IC attachment logic to check whether @@hasInstance
is defined anywhere below Function in the prototype chain of the RHS. If not,
it is still safe to attach the IC; the IC simply needs to guard on the
prototype chain to ensure no @@hasInstance override is inserted later.
Differential Revision: https://phabricator.services.mozilla.com/D42366
--HG--
extra : moz-landing-system : lando
Most live nursery strings can be deduplicated in moveToTenured through a hashset.
Dependent strings are complicated to deal with since their chars need to be updated with the newly deduplicated base chars.
If the dependent string is tenured, its bases cannot be deduplicated since a tenured dependent string chars cannot be updated. Otherwise, the following steps will be able to update its chars.
1. Preserve the nursery base chain by saving dependent string nursery bases in its relocation overlay. This allows dependent string nursery root base to be reached.
2. Calculate the original dependent string base offset: dependent string nursery chars - dependent string root base nursery chars. Root base nursery chars is saved in its relocation overlay.
3. Update the dependent string chars with its new root base chars and the calculated offset.
4. Assign either the root base or the undepended string in which the dependent string uses chars from as the new base to unchain any potentially long dependency chain.
Differential Revision: https://phabricator.services.mozilla.com/D39440
--HG--
extra : moz-landing-system : lando
This makes it easier to see the implementation for a particular platform
without getting confused by code for other platforms.
The SPARC code was deleted because we don't have a JIT backend for it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D42804
--HG--
extra : moz-landing-system : lando
If either the Realm or the request needs full-parsing, we disable lazy
parsing.
Differential Revision: https://phabricator.services.mozilla.com/D42560
--HG--
extra : moz-landing-system : lando
We already have an accessor to make sure this is can only be set but not
cleared so hide the underlying storage.
Differential Revision: https://phabricator.services.mozilla.com/D42559
--HG--
extra : moz-landing-system : lando
The hasIntroductionInfo flag is equivalent to checking for the existance
introducerFilename so use that instead. Also remove unused setter for
the introducer script.
Differential Revision: https://phabricator.services.mozilla.com/D42558
--HG--
extra : moz-landing-system : lando
If either the Realm or the request needs full-parsing, we disable lazy
parsing.
Differential Revision: https://phabricator.services.mozilla.com/D42560
--HG--
extra : moz-landing-system : lando