Historically, we had configure.in in the tree, and generated configure
with autoconf via client.mk at build time, and we'd run that configure.
As a side effect, configure would be shipped in source tarballs, as with
traditional autoconf-driven software.
Bug 1671424 changed that, and made `mach build`/`mach configure` invoke
configure.py directly, without needing configure. As a side effect,
configure stopped being generated in source directories. An unexpected
side effect was that configure stopped being shipped in source tarballs.
Anyways, it has been long enough now that adding a configure file in the
tree shouldn't cause too many problems with people updating their trees
where a configure file might exist from those older builds.
Differential Revision: https://phabricator.services.mozilla.com/D155923
This matches StoreFixedSlot and MStoreDynamicSlot and makes it more explicit
when pre-barriers are omitted.
Depends on D155681
Differential Revision: https://phabricator.services.mozilla.com/D155682
All callers are now passing `MIRType::Value`, so we can remove the `slotType` parameter
and simplify the methods.
Depends on D155680
Differential Revision: https://phabricator.services.mozilla.com/D155681
There aren't any callers to `setSlotType()`, which means `slotType` is always
equal to `MIRType::Value`.
Drive-by change:
- Remove unused method `setNeedsBarrier()`.
Depends on D155679
Differential Revision: https://phabricator.services.mozilla.com/D155680
Change the `StoreElementHoleT` to also pass `MIRType::Value` instead of `MIRType::None`.
This doesn't change the behaviour because `valueType` is definitely specialized, so we
will still store the type tag.
Depends on D155676
Differential Revision: https://phabricator.services.mozilla.com/D155677
This patch adds an overview of the data structures and core algorithms of the
backtracking allocator. NO FUNCTIONAL CHANGE.
Differential Revision: https://phabricator.services.mozilla.com/D151729
There's no point using a helper thread if we're going to wait for it
immediately. We do perform non-incremental GCs sometimes (and in shutdown) and
this avoids the possibility of scheduling issues affecting us.
This applies to background sweeping, decommiting and unmarking.
(I think I argued against this at one point, but I've come round to thinking
it's a good idea.)
Differential Revision: https://phabricator.services.mozilla.com/D155610
We have an extra check in DoMarking that allows gray marking in the atoms zone
even when it's in the marking black only state. It's simpler to start this zone
in the marking black and gray state and remove the special case.
The reason for this case is that we can't delay gray marking in zones that are
marking black only for atoms like we do for objects. In that case we push the
CCWs into the black zone on a list and mark them later when that zone
transitions to black and gray marking. But the atoms zone may have direct
references from any zone that don't go through CCWs.
Differential Revision: https://phabricator.services.mozilla.com/D155605
Add emplace methods to JSString and BigInt types to reduce amount of C++
undefined-behaviour by running the constructor of the concrete derived type.
This is in contrast to previous behaviour of allocating a gc::Cell and then
simply casting to the final type. We still first allocate as a Cell from the GC
and then use placement-new to initialize as the correct type.
Differential Revision: https://phabricator.services.mozilla.com/D134095
It's probably possible to juggle registers around to make this work on 32-bit x86, but it doesn't seem worthwhile. `copyToScratchValueRegister` doesn't work, because `AutoCallVM::prepare` uses the output as a scratch register.
I added one testcase specifically targeting the original fuzzbug, and another slightly broader testcase based on the testcase we added for `tryAttachGenericElement` (bug1488786.js).
Differential Revision: https://phabricator.services.mozilla.com/D155298
This allows to scalar replace the `MNewCallObject` in cases like:
```js
function f() {
var r = 0;
for (var i = 0; i < 100; ++i) {
var fn = i => () => i;
r += fn(i)();
}
return r;
}
```
This code is compiled to:
```
48 lambda newcallobject43:Object constant47:Object
53 guardtofunction lambda48:Object
54 guardfunctionscript guardtofunction53:Object
57 functionenvironment guardfunctionscript54:Object
```
`MGuardToFunction` and `MGuardFunctionScript` weren't present in Ion when scalar
replacement support for `MNewCallObject` was originally implemented. For Warp
we need to handle those two instructions, too.
There aren't any new tests, because `MNewCallObject` is an implementation detail
and can't be tested from JS. (The `MLambda` is already scalar replaced without
this change.)
Differential Revision: https://phabricator.services.mozilla.com/D155470
When generating bytecode, we are looking for names locations, using
`ScopeContext::searchInEnclosingScope`, to replace them by integers, which
improve the speed of the generated code.
However, looking for these names can it-self be extremlly costly if there is a
scope with a very large number of bindings. Multiple attempts have been made in
the past to improve this situation by caching bindings within the scope of each
compilation. Unfortunately, this was either a regression or a non-improvement,
as these lookups might be done by thousands of inner functions.
This patch adds content to the `ScopeBindingCache`, introduced in the previous
patch as placeholder. The `ScopeBindingCache` is a cache which persists across
multiple compilations. Therefore, if a scope chain is shared by multiple
delazified inner function, the caching cost would be mutualized.
The `ScopeBindingCache`, as the `searchInEnclosingScope` function have to deal
with 2 different kind of scopes. Either we are manipulating stencils, in case of
concurrent delazification, or we are manipulating GC objects, in case of
on-demand delazification. Thus the interface provide overloaded functions to be
able to write generic code, and contains 2 `ScopeBindingMap`, one for each type
of atoms `TaggedParserAtomIndex` and `JSAtom*` respectively coming from scope
`*::ParserData` and `*::RuntimeData` of each scope.
The `ScopeBindingMap` is a `HashMap` indexed on the `AbstactBaseScopeData` for
each Atom type. It maps the scope data, i-e the pointer to the array of
bindings, to the `BindingMap`.
The `BindingMap` provides a `HashMap` and a `catchAll` field. The `HashMap` is
used to map each binding to its `NameLocation`, while the `catchAll` is used to
handle the case where the scope is used to collect all new names, when
dynamically created.
The `BindingMap`'s `hashMap` makes use of the lookup capability of `HashTable`
in order to avoid storing the context of each atom next to each key. As all
bindings are coming from the same scope data. Thus the `Lookup` provides the
context to interpret the keys which are stored in the `hashMap`. This `HashMap`
also feature the ability to compare all 3 different atoms possible. The
comparisons between these 3 different atoms is handled by the `GenericAtom`
class.
The `GenericAtom` class provides a uniform interface for comparing the 3
different type of atoms against each others, such that atoms can be registered
in the `BindingMap` with one type, while being look up with the same or
different type. The `GenericAtom` exposes a `hash` field, which is consistent
across all atoms types, as well as an equality operator. The 3 different atoms
types are: `TaggedParserAtomIndex` provided by the `ScopeStencilRef`, the
`TaggedParserAtomIndex` provided by the `ParserAtomTable` and the `JSAtom*` from
GC objects.
Differential Revision: https://phabricator.services.mozilla.com/D154514
This patch isolate the boiler plate code to create a dummy ScopeBindingCache
with no logic to split the noise of this not-so mechanical patch driven by
compiler error messages.
This patch modify the interface of every function, adding the option to provide
a custom ScopeBindingCache when parsing a Stencil, except for publicly facing
functions such as from `js/public/experimental/JSStencil.h`.
The intent being that Helper thread functions, which are relying on Stencil
should have their own ScopeBindingCache which is either unused, or dedicated to
caching the bindings of multiple delazifications. The reasons are that in the
future we are interested in stripping the JSContext* out of HelperThreads, and
that there is no value in sharing the content across threads.
Differential Revision: https://phabricator.services.mozilla.com/D154513
This patch adds 2 short-circuits to improve the lookup of bindings in the
enclosing scope chain, during on-demand delazification.
The first short-circuit is in Function scope, by comparing bindings against each
others, we can compare either `JSAtom` directly against `JSAtom` or
`TaggedParserAtomIndex` directly with `TaggedParserAtomIndex` from the
CompilationStencil context.
The second short-circuit is in `InputName::isEqualTo`, in the case where we are
comparing a `JSAtom` against the `TaggedParserAtomIndex` from the compiled
script, we can query the hash of both and compare them before converting the
`TaggedParserAtomIndex` into a `JSAtom`, which should make the comparison
faster.
Differential Revision: https://phabricator.services.mozilla.com/D154511
This patch moves the hops offseting out of the `searchInEnclosingScope`
computation such that `searchInEnclosingScope` computation can provide a result
which is independent from where the named is looked for. Making the NameLocation
independent enables us to later cache the NameLocation.
Differential Revision: https://phabricator.services.mozilla.com/D154510
We check for pre-barrier verification during marking. This simplifies the
shouldMarkInZone() check so we only need to check the zone's GC state.
Differential Revision: https://phabricator.services.mozilla.com/D154971
Cosmin Sabou
Mike Hommey
Sandor Molnar
Yoshi Cheng-Hao Huang
André Bargull
Julian Seward
Mark Banner
Jon Coppeard
criss
Steve Fink
Butkovits Atila
Iain Ireland
Nicolas B. Pierron
Tooru Fujisawa