Each concurrent marking task maintains task_state[i]->marked_bytes.
When a task finishes, its local counter is flushed into global
total_marked_bytes_ atomic counter.
Bug: chromium:694255
Change-Id: I629467385e80bf229e06a4231673ceb5ef8e4aea
Reviewed-on: https://chromium-review.googlesource.com/704823
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48374}
Missing arguments are identical to undefined, and are converted to the
integer 0 by ECMAScript {ToInteger()}.
Add more tests, and enable previously disabled tests.
There is a follow-up refactoring here: https://crrev.com/c/704586R=titzer@chromium.org, mstarzinger@chromium.org
Change-Id: I89cc259aaf5975ec2f6f51ff002e7d1b32adba5e
Reviewed-on: https://chromium-review.googlesource.com/704658
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48373}
We can use the known ElementsKind to improve typing on the receiver
element load. We can allow multiple maps, as long as they have the
same ElementsKind.
Bug: v8:6896
Change-Id: Ida7df943f7d315454b58bcf4e0bbd2346406c488
Reviewed-on: https://chromium-review.googlesource.com/704921
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48367}
Now, the EffectControlLinearizer connects all occurrences of Unreachable to the
graph end. This fixes issues with later phases running DeadCodeElimination and
introducing new DeadValue nodes when processing uses of Unreachable.
This is a reland of 3c4bc27f13
Original change's description:
> Reland "[turbofan] eagerly prune None types and deadness from the graph"
>
> This is a reland of e1cdda2512
> Original change's description:
> > [turbofan] eagerly prune None types and deadness from the graph
> >
> > In addition to using the {Dead} node to prune dead control nodes and nodes that
> > depend on them, we introduce a {DeadValue} node representing an impossible value
> > that can occur at any position in the graph. The extended {DeadCodeElimination}
> > prunes {DeadValue} and its uses, inserting a crashing {Unreachable} node into
> > the effect chain when possible. The remaining uses of {DeadValue} are handled
> > in {EffectControlLinearizer}, where we always have access to the effect chain.
> > In addition to explicitly introduced {DeadValue} nodes, we consider any value use
> > of a node with type {None} as dead.
> >
> > Bug: chromium:741225
> > Change-Id: Icc4b636d1d018c452ba1a2fa7cd3e00e522f1655
> > Reviewed-on: https://chromium-review.googlesource.com/641250
> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48208}
>
> Bug: chromium:741225
> Change-Id: I21316913dae02864f7a6d7c9269405a79f054138
> Reviewed-on: https://chromium-review.googlesource.com/692034
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48232}
Bug: chromium:741225
Change-Id: I5702ec34856c075717162153adc765774453c45f
Reviewed-on: https://chromium-review.googlesource.com/702264
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48366}
The escape analysis is able to perform scalar replacement on JSArrays
with in-object properties (which currently only happens for subclasses
of the Array constructor), but the Deoptimizer didn't properly
materialized and initialized the values of the in-object fields so far.
Bug: chromium:772689, v8:6399
Change-Id: I6555a46773d2a1543db069142aa05f4337566b9c
Reviewed-on: https://chromium-review.googlesource.com/706781
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48365}
These will be used in subsequent CLs to add spec-compliant builtins
on Array.prototype built with the CSA.
Change-Id: I4c9f72f90dffe018b99efdc73e9d40b3d175c2aa
Reviewed-on: https://chromium-review.googlesource.com/704115
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48362}
This adds a new operator LookupSigned32HashStorageIndex, which is a
specialization of the general LookupHashStorageIndex for Map#get that
is used when TurboFan knows that the key is in Signed32 range.
This improves the execution time of the ARES6 Basic test locally by
around 5% and seems to make sense in general.
Bug: v8:6410, v8:6354, v8:6278, v8:6344
Change-Id: I78dcbc9cc855a4109e1690d8cd14fbc88fd89861
Reviewed-on: https://chromium-review.googlesource.com/706787
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48361}
Rewrites import.meta expressions into null literals. Builds on top
of- and requires dynamic import parsing to simplify the implementation.
Adds a new --harmony-import-meta flag.
BUG=v8:6693
Change-Id: Iadb7ddf6bad8986bf3ad641dbd3826fe730b5f44
Reviewed-on: https://chromium-review.googlesource.com/702678
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48359}
Use case: anonymous script with sourceMappingUrl. User can set
breakpoint in source with sourceUrl from sourceMap, we persist this
breakpoint in DevTools and on page reload breakpoint should be restored
correctly.
Debugger.setBreakpointByUrl method provides capabilities to set
provisional breakpoints and looks like best candidate for new "scriptHash"
argument.
I considered other options such as replacing scriptId with something
more persistent like "script-hash:script-with-this-hash-number" but it
looks more complicated and doesn't provide clear advantages.
One pager: http://bit.ly/2wkRHntR=pfeldman@chromium.org
Bug: chromium:459499
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I0e2833fceffe6b04afac01d1a4522d6874b6067a
Reviewed-on: https://chromium-review.googlesource.com/683597
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48357}
Further optimize the
new Array(n)
expressions by also inlining the backing store allocation into TurboFan
optimized code. Currently these backing store allocations cannot be
eliminated by escape analysis and can also not be optimized further by
the memory optimizer (i.e. no allocation folding and not write barrier
elimination) yet, but this can be done in follow-up CLs.
This yields another ~5% improvement on the ARES6 ML benchmark (steady
state).
Drive-by-fix: Add support for loops to the GraphAssembler. This was
necessary to implement the initialization loops in for the backing
store allocations in the EffectControlLinearizer.
Bug: v8:6399, v8:6901
Change-Id: I759d6802db01eb797e78c7d82d82caaee3463e16
Reviewed-on: https://chromium-review.googlesource.com/705934
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48352}
The twodigit_t code path emitted a library call rather than
a hardware "div" instruction. This is because compilers are
playing it safe: "div" can overflow when the divisor is too
small. Our algorithm carefully avoids this though, so using
the hardware "div" instruction is safe.
This speeds up a microbenchmark by almost 50%.
Bug: v8:6791
Change-Id: I35a73f8acdaca24f18327fbdaf7f53c4fd450c40
Reviewed-on: https://chromium-review.googlesource.com/686002
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48351}
The typical pattern for using BuildCCall was to create a stack-allocated array
of arguments, which was passed to BuildCCall. BuildCCall then would allocate
scratch space using WasmGraphBuilder::Buffer and copy the arguments into the
scratch space. This copy is unnecessary and also the use of Buffer can lead to
silently overwriting scratch space that may be used higher up the stack.
Now BuildCCall takes all of the functions parameters as arguments and stores
this directly in a stack-allocated buffer, avoiding the use of Buffer at all and
all its associated pitfalls.
Change-Id: Ia0de9a90350d7fcbbb1b05d28e735d790a5f9143
Reviewed-on: https://chromium-review.googlesource.com/701638
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48350}
Make calls like
new Array(n)
new A(n)
(where A is a subclass of Array) inlinable into TurboFan. We do this by
speculatively checking that n is an unsigned integer that is not greater
than JSArray::kInitialMaxFastElementArray, and then lowering the backing
store allocation to a builtin call. The speculative optimization is
either protected by the AllocationSite for the Array constructor
invocation (if we have one), or by a newly introduced global protector
cell that is used for Array constructor invocations that don't have an
AllocationSite, i.e. the ones from Array#map, Array#filter, or from
subclasses of Array.
Next step will be to implement the backing store allocations inline in
TurboFan, but that requires Loop support in the GraphAssembler, so it's
done as a separate CL. This should further boost the performance.
This boosts the ARES6 ML benchmark by up to 8% on the steady state,
and also improves monomorphic Array#map calls by around 20-25% on the
initial setup.
Bug: v8:6399
Tbr: ulan@chromium.org
Change-Id: I7c8bdecf7c814ce52db6ee3051c3206a4f7d4bb6
Reviewed-on: https://chromium-review.googlesource.com/704639
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48348}
This brings V8's behavior in line with both the spec and with
other engines.
This also fixes the (now-incorrect) DCHECK in BytecodeGenerator relating
to the delete operator's application to a VariableProxy.
Bug: v8:6697, v8:6721
Change-Id: I413c02af235b0bb652eb4c5d5c971e2cf80e0906
Reviewed-on: https://chromium-review.googlesource.com/703894
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48346}
Also remove vogelheim (no longer on the team) for clarity.
Change-Id: Ida6d058252f17b71bb158308657ae2d18b52c2b2
Reviewed-on: https://chromium-review.googlesource.com/703161
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48345}
Avoid splitting functionality in two interface calls and passing around
a void* between them.
R=kschimpf@chromium.org
Change-Id: I0e12ff0295852ce5c36f7c3fb3b2c51dc0f2677e
Reviewed-on: https://chromium-review.googlesource.com/702484
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48335}
Currently, the transition elements kind operation invalidates the
elements of all other arrays. In particular, if we loop over matrix
elements using two nested loops, and do possibly transitioning access
a[i][j] in every iteration, we invalidate the load elimination state
for the array 'a' because a[i][j] might transition elements kind
for the 'a[i]' array. As a result, the 'a[i]' access cannot be
hoisted from the inner loop.
With this CL, we figure out that transitioning 'a[i]' cannot affect 'a'
because we know that 'a' does not have the transition's source map.
In the micro-benchmark below, the time for summing up the elements of
100x100 matrix improves by factor of 1.7 (from ~340ms to ~190ms).
function matrixSum(a) {
let s = 0;
let rowCount = a.length;
let columnCount = a[0].length;
for (let i = 0; i < rowCount; i++) {
for (let j = 0; j < columnCount ; j++) {
s += a[i][j];
}
}
return s;
}
// Setup the matrices:
// Smi elements.
var ma = [[1, 2], [3, 4]];
// Holey double elements.
var b = Array(100);
for (let i = 0; i < 100; i++) b[i] = 1.1;
var mb = [];
for (let i = 0; i < 100; i++) mb[i] = b;
// Warmup.
matrixSum(mb);
matrixSum(mb);
matrixSum(ma);
matrixSum(mb);
matrixSum(ma);
%OptimizeFunctionOnNextCall(matrixSum);
function runner(m) {
let s = 0;
for (let i = 0; i < 1e4; i++) {
s += matrixSum(m);
}
return s;
}
// Make sure the runner does not know the elements kinds.
%NeverOptimizeFunction(runner);
// Measure.
console.time("Sum");
runner(mb);
console.timeEnd("Sum");
Bug: v8:6344
Change-Id: Ie0642d8693ed63116b1aaed7d2f261fcb64729fe
Reviewed-on: https://chromium-review.googlesource.com/704634
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48334}
And other cleanups to reuse computed function names, and use
EmbeddedVector instead of ScopedVector (stack allocated instead of heap
allocated).
R=titzer@chromium.org
Change-Id: Id293946dc9aa574e7d185ff23b87068bca74549f
Reviewed-on: https://chromium-review.googlesource.com/690474
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48332}
