- Make it possible to store quarter-bytes instead of full bytes.
- Don't store is_used; it can be recovered correctly based on the actual full
parse (when a lazy function is eventually called) and
has_forced_scope_allocation.
- With the is_used change, the old testing approach (which compared a scope for
which we didn't do scope allocation to the baseline) no longer made
sense. Replaced it with a new testing approach, which is also closer to the
actual usage.
- First version (reverted): https://chromium-review.googlesource.com/725422
BUG=v8:5516
Change-Id: I1468af6670b689a104bd867377caa1d236070820
Reviewed-on: https://chromium-review.googlesource.com/733123
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48903}
This introduces the {CodeDataContainer} as a container for all mutable
fields associated with a {Code} object. For now only the kind-specific
flags are moved, but more fields can/will be moved gradually. The goal
is to make all fields in the {Code} header be immutable eventually.
R=jarin@chromium.org
BUG=v8:6792
Change-Id: I2eeba893afaba877fb6117e1f18371898c3a175e
Reviewed-on: https://chromium-review.googlesource.com/732987
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48902}
Body descriptors are used by marking and scavenging visitors.
Change-Id: I6912bb5b924755db5750f0a3b1e4909bff5375c7
Reviewed-on: https://chromium-review.googlesource.com/732978
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48901}
Otherwise, the quiet NaN bit might flip already when loading the
float/double from memory or storing it.
This fixes another NaN bit flip which happened on a single bot only.
R=titzer@chromium.org
Bug: v8:6954
Change-Id: Ica9be71db9c5b505302686e9c0a4b1cae020a7e4
Reviewed-on: https://chromium-review.googlesource.com/735320
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48900}
We found this while trying to integrate V8 6.3 into Node.js. One of the
tests started to crash on Windows.
https: //github.com/nodejs/node/pull/16271#issuecomment-337790715
Bug:
Change-Id: I82514ff7b9ca6a2b5c4489fe7388c4beda9931c9
Reviewed-on: https://chromium-review.googlesource.com/735400
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Michaël Zasso <mic.besace@gmail.com>
Cr-Commit-Position: refs/heads/master@{#48899}
Elements on typed arrays are never looked up in the prototype chain, so
there's no point in depending on the prototype chain validity cells for
keyed stores to typed arrays. You just risk going megamorphic for
unrelated changes.
Bug: v8:6999
Change-Id: Id831de42a2c9eadfd5317ee9b5dbfaa207f236fe
Reviewed-on: https://chromium-review.googlesource.com/737789
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48898}
as opposed to waiting until state() is PREMONOMORPHIC like named
Load/StoreICs do. Keyed ICs do not have PREMONOMORPHIC state.
Bug: v8:6999
Change-Id: If37705d3301fb93a2fc2bf10fdeb255ff06fdb5e
Reviewed-on: https://chromium-review.googlesource.com/737655
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48895}
I am not committing the regression test from the bug because it takes
ages to run, but I have locally verified that it passes now.
Bug: chromium:776645
Change-Id: Ia7128d9fa3cf864b1c1b646802a973fe41d4c4ae
Reviewed-on: https://chromium-review.googlesource.com/735484
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48893}
This CL makes --trace-maps available in the default build by disabling
certain expensive/intrusive features.
This is an intermediate step to be able to write proper tests for --trace-maps
and the new map-processor.
Change-Id: Ib6a8fc9c77796c106d3af9d741d48abe6c6b9099
Reviewed-on: https://chromium-review.googlesource.com/734648
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48891}
It appears in the cctest context, both the old STUB, and the current
WASM_FUNCTION "just work"; however, in the upcoming off-the-gc wasm
world, we codegen call sites differently on x64 - far calls for
js-to-wasm (this case), and near calls otherwise.
Bug:
Change-Id: Iebf8acf164f07742fc367b7bbf266913dbc60c46
Reviewed-on: https://chromium-review.googlesource.com/735131
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48889}
Before, the standard way to create a RegList was either:
RegList list = (1 << 0) | (1 << 1) | ...
or
RegList list = rax.bit() | rdx.bit() | ...
The first way allows to make the RegList constexpr, but needs comments
to document which registers you are referring to, and it has no checks
that all bits you set on the RegList actually belong to valid registers.
The second one uses the symbolic names, hence is much more readable and
makes it harder to construct invalid RegLists. It's not constexpr
though, since the {bit()} method on the register types is not constexpr.
This CL adds a constexpr accessor to get the code and bit of a
constexpr Register, and adds a helper method to create a constexpr
RegList like this:
constexpr RegList list = Register::ListOf<rax, rdx, rdi>();
This new method is used in a number of places to test its
applicability. Other uses of the old pattern remain and can be cleaned
up later.
R=tebbi@chromium.org
Change-Id: Ie7b1d6342dc5f316dcfedd0363b3540ad5e7f413
Reviewed-on: https://chromium-review.googlesource.com/728026
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48887}
Similar to the incremental marker, rename the MarkingState to
MajorMarkingState and avoid using atomics on live byte count as the
concurrent tasks cache its value.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Bug: chromium:750084
Change-Id: Id37bb89385d4fbae95542073ea652617e61010d5
Reviewed-on: https://chromium-review.googlesource.com/735399
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48885}
This removes all but one caller of Literal::raw_value(), thus
hiding AstValue from the rest of the codebase. This is in
preparation to move much of AstValue's implementation up
into Literal itself, thus avoiding the overhead of the
underling ZoneObjects and allowing us to remove complexity
such as the cache of Smi-valued AstValues.
Bug: v8:6984
Change-Id: I1b90aa64b9d26db36ef486afe73cda4473ef866e
Reviewed-on: https://chromium-review.googlesource.com/731109
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48884}
Only rewind destructuring assignments if we actually preparsed
the arrow function. For the case of single-expression bodies,
we don't preparse, but we were previously erroneously rewinding.
Bug: v8:6970
Change-Id: I38e15a8a5bdb05abee3bafe7bbd7736b55a6950b
Reviewed-on: https://chromium-review.googlesource.com/733950
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48883}
This is to enable it to also be used for reporting AsmJS errors such that
this can be moved off-thread.
BUG=v8:5203
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia46040b14d010702f10c02b8254aea84cba4d54d
Reviewed-on: https://chromium-review.googlesource.com/735606
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48881}
This moves bits that are accessed during a stack-walk out if the first
kind-specific flags field. Such bits are accessed during evacuation
within the GC and hence need to remain directly in the {Code} object,
the other bits in the kind-specific flags are mutable and hence will be
moved into a separate data container object.
R=jarin@chromium.org
BUG=v8:6792
Change-Id: I20b7d307110ca0c0eb6dd4df31a35fab4701c6da
Reviewed-on: https://chromium-review.googlesource.com/735145
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48877}
Our first implementation passed the source position as argument to the
runtime function, which would then generate an Error object, patch the
contained stack trace to point to the position given as argument, and
then throw the Error.
Since all our paths are now changed to call a builtin with proper
source position information, we do not need to patch anything any more.
R=ahaas@chromium.org
Bug: v8:5007
Change-Id: I70dce1b9fcf9966a13865c1c373f3e354908b009
Reviewed-on: https://chromium-review.googlesource.com/732117
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48876}
... mainly by adapting Object::Compare and
CodeStubAssembler::RelationalComparison.
TBR=rmcilroy@chromium.org
Change-Id: I34448d45b4950b9318263c4a667aa9db7d77232d
Bug: v8:6791
Reviewed-on: https://chromium-review.googlesource.com/730730
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48873}
This speeds up insertion and removal by reducing the time taken to hash.
Bug: v8:6992
Change-Id: I4e9e1c97a5503bf5a09c2428980a3c2d6bf4051e
Reviewed-on: https://chromium-review.googlesource.com/735419
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48867}
When lowering a monomorphic load/store, where multiple receiver maps
have been recorded, but the action to be performed is the same (i.e.
yielding undefined because the property is not found), TurboFan used
to ignore the Smi case, leading to a pretty terrible deoptimization
loop, as the LOAD_IC/STORE_IC properly recorded that state and thus
didn't change it's state.
Fixing this issue gives a 18-20% boost on the prettier test of the
web-tooling-benchmark, which was suffering a lot from this problem.
Bug: v8:6936, v8:6991
Change-Id: Id208ec7129a7f6b190d989bda31f936040393226
Reviewed-on: https://chromium-review.googlesource.com/735342
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48865}
Ensure that effect outputs from nodes are used if they have
an effect output. This helps us avoid an easy-to-make error
where we fail to update the effect chain with the result of
effectful operations.
Bug: v8:6929
Change-Id: I585dc627b3c330006ec04717ff9b2f5060dbad6a
Reviewed-on: https://chromium-review.googlesource.com/718107
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48861}
Avoid locking the pages for the scavenger by filtering out pages that require
sweeping and scavenging from the sweeper. This way we preserve the assumption
that processing slots on a page is sequential.
Pages that have been scavenged are re-added to the sweeper to allow them to
be reused for allocation.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Bug: v8:6923
Change-Id: I7d159de11792ef16a534f29e31791d06d7fb5221
Reviewed-on: https://chromium-review.googlesource.com/730603
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48859}
Once the KeyedStoreIC was in MEGAMORPHIC state storing to dictionary
mode objects, we'd constantly hit the slow-path implemented via the
%SetProperty runtime function, if the dictionary was created with a
null prototype, i.e. via Object.create(null). This goes against the
advice of using Object.create(null) for dictionaries (compared to
using empty object literal), which is unfortunate.
This CL addresses two issues, starting with
- adding support for null prototypes to LookupPropertyOnPrototypeChain,
which was always hitting the slow path for null prototypes, and
- using the dedicated %AddDictionaryProperty runtime call when we
have to grow the backing store.
These changes combined improve the micro-benchmark from
storeToDictionary: 559 ms.
storeToFast: 95 ms.
to
storeToDictionary: 201 ms.
storeToFast: 94 ms.
which reduces overhead by about 65%. This overall improves the chai test
on the web-tooling-benchmark by about 4%, which still leaves some room
for improvement.
Bug: v8:6936, v8:6985
Change-Id: I97b78961f51edb3a3e198bdb31457fd78bed947f
Reviewed-on: https://chromium-review.googlesource.com/735139
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48858}
The (KEYED_)LOAD/STORE_ICs didn't properly leave the UNINITIALIZED as
long as the receiver was always null/undefined. This leads to
deoptimization loops in TurboFan, because the compiler always put in a
SOFT deoptimization at this point.
Bug: v8:6989
Change-Id: I1a32bfb722f121f8b593e8972e657290d7b0531d
Reviewed-on: https://chromium-review.googlesource.com/735319
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48854}
