Review-Url: https://codereview.chromium.org/2570813002
Cr-Commit-Position: refs/heads/master@{#41672}

It reduces the add operation for certain checked load/stores by pre-do the add in compiling phase.

BUG=

Review-Url: https://codereview.chromium.org/2563483005
Cr-Commit-Position: refs/heads/master@{#41671}

The assignment in default parameters (e.g., function foo(a = somedefault) { }
doesn't flow through PreParserFactory::NewAssignment even if the comment claims so.
Thus, piping through the variables is not needed.

Kudos to neis@ for pointing this out.

BUG=v8:5501
R=neis@chromium.org

Review-Url: https://codereview.chromium.org/2569983003
Cr-Commit-Position: refs/heads/master@{#41670}

There was previously a race between different phases recording their
first entry -- and thus, their insert order -- on the main and
concurrent-compilation thread. This would later manifest as a segfault
when creating the sorted array of phases for --turbo-stats (as two
phases would have the same insert order and so there would be a gap in
the array).

Review-Url: https://codereview.chromium.org/2572713003
Cr-Commit-Position: refs/heads/master@{#41669}

R=jochen@chromium.org, peria@chromium.org
BUG=chromium:617892

Review-Url: https://codereview.chromium.org/2571743002
Cr-Commit-Position: refs/heads/master@{#41668}

Revert of [deoptimizer] Enable test that should no longer fail. (patchset #1 id:1 of https://codereview.chromium.org/2568723003/ )

Reason for revert:
Still flakes on ARM.

Original issue's description:
> [deoptimizer] Enable test that should no longer fail.
>
> R=jarin@chromium.org
> TEST=cctest/test-cpu-profiler/CollectDeoptEvents
>
> Committed: https://crrev.com/3f9c2c590d687562d6adb531d1159738c07013f4
> Cr-Commit-Position: refs/heads/master@{#41664}

TBR=jarin@chromium.org,machenbach@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2568403003
Cr-Commit-Position: refs/heads/master@{#41667}

incremental marking.

BUG=chromium:671994

Review-Url: https://codereview.chromium.org/2565173004
Cr-Commit-Position: refs/heads/master@{#41666}

Revert of [heap] Enable black allocation when finalizing marking. (patchset #3 id:40001 of https://codereview.chromium.org/2440943002/ )

Reason for revert:
Seems to block roll:
https://codereview.chromium.org/2569133002/

Original issue's description:
> [heap] Enable black allocation when finalizing marking.
>
> BUG=chromium:630386
>
> Committed: https://crrev.com/a98d971412a5c32967bbef4b77b9d2658055ff1c
> Cr-Commit-Position: refs/heads/master@{#41655}

TBR=ulan@chromium.org,hpayer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:630386

Review-Url: https://codereview.chromium.org/2567353002
Cr-Commit-Position: refs/heads/master@{#41665}

R=jarin@chromium.org
TEST=cctest/test-cpu-profiler/CollectDeoptEvents

Review-Url: https://codereview.chromium.org/2568723003
Cr-Commit-Position: refs/heads/master@{#41664}

https://crrev.com/c3a6ca68d0646b10885ef7017557eaf463db2e4a changed what kind of information is dumped which broke some properties of the output that IRHydra relies on:

1. Because IRHydra does not have access to the whole scripts it relies on function sources dumps to map IR and deoptimization to the actual source. This means that source positions must be dumped in a way that allows for this mapping and previously we used positions relative to the beginning of the function to allow that. Now we are dumping absolute script positions which means that function sources must be annotated with the start position so that IRHydra (or any other similar tools) could translate absolute script positions into function-relative ones.

2. When dumping inlined functions we should dump which function are we inlining into because position itself is not enough to recover the inlining stack from the output.

BUG=

Review-Url: https://codereview.chromium.org/2573653002
Cr-Commit-Position: refs/heads/master@{#41663}

Review-Url: https://codereview.chromium.org/2569663003
Cr-Commit-Position: refs/heads/master@{#41662}

Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/7321edc..52f7afe

Rolling v8/third_party/catapult: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+log/19565fd..c69690a

Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/53bdedc..7e13606

TBR=machenbach@chromium.org,vogelheim@chromium.org,hablich@chromium.org

Review-Url: https://codereview.chromium.org/2566153004
Cr-Commit-Position: refs/heads/master@{#41661}

BUG=v8:5343

Review-Url: https://codereview.chromium.org/2571663002
Cr-Commit-Position: refs/heads/master@{#41660}

  Currently the jump label's distance value in LCodeGen::DoWrapReceiver() of X86 is unconsistent.

  For avoiding potential bugs caused by this unconsistent usage for the same label when DeoptEveryNTimes()
  return true, This CL unify the label's distance value usage in LCodeGen::DoWrapReceiver().

  For more informations, please refer CL #41419 (https://codereview.chromium.org/2539403002/ ).

BUG=

Review-Url: https://codereview.chromium.org/2554493002
Cr-Commit-Position: refs/heads/master@{#41659}

When ParseOnBackground is done, we should construct a trace event and dump all
background parsing runtime statistics as argument. In tracing we don't want to
merge it back to to main thread, instead we show the trace event together with
background parsing trace event on script streamer thread track in Trace Viewer.

To perf sheriff: A series of counters ParseBackgroundxxx and
PreparseBackgroundxxx will be taken into account in this patch, thus runtime
statistics graph will increase after this patch gets landed.

BUG=v8:5089

Review-Url: https://codereview.chromium.org/2559403002
Cr-Commit-Position: refs/heads/master@{#41658}

This is to improve the performance of common operation of
extracting contextId or contextGroupId out of Context.

BUG=none

Review-Url: https://codereview.chromium.org/2558913004
Cr-Commit-Position: refs/heads/master@{#41657}

...and HasProperty, for dictionary-elements receivers.

BUG=chromium:673008

Review-Url: https://codereview.chromium.org/2568943002
Cr-Commit-Position: refs/heads/master@{#41656}

BUG=chromium:630386

Review-Url: https://codereview.chromium.org/2440943002
Cr-Commit-Position: refs/heads/master@{#41655}

BUG=

Review-Url: https://codereview.chromium.org/2566133002
Cr-Commit-Position: refs/heads/master@{#41654}

BUG=

Review-Url: https://codereview.chromium.org/2568173002
Cr-Commit-Position: refs/heads/master@{#41653}

R=bradnelson@chromium.org,ishell@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2570543002
Cr-Commit-Position: refs/heads/master@{#41652}

BUG=

Review-Url: https://codereview.chromium.org/2568713002
Cr-Commit-Position: refs/heads/master@{#41651}

It doesn't schedule steps yet, but there are tests.

BUG=v8:5215
R=rmcilroy@chromium.org,marja@chromium.org

Review-Url: https://codereview.chromium.org/2558293004
Cr-Commit-Position: refs/heads/master@{#41650}

All issues in interpreter bytecode handlers are fixed.

BUG=

Review-Url: https://codereview.chromium.org/2552883012
Cr-Commit-Position: refs/heads/master@{#41649}

Generalize Messages to include an error level.
Add a parameter to AddMessageHandler to select which error levels to receive, using a mask (default being just errors, i.e. the current behavior).

BUG=v8:4203
R=dgozman@chromium.org,machenbach@chromium.org,danno@chromium.org,bmeurer@chromium.org,jochen@chromium.org

Review-Url: https://codereview.chromium.org/2526703002
Cr-Commit-Position: refs/heads/master@{#41648}

BUG=672789
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2559113006
Cr-Commit-Position: refs/heads/master@{#41647}

BUG=

Review-Url: https://codereview.chromium.org/2562383002
Cr-Commit-Position: refs/heads/master@{#41646}

BUG=v8:5501, v8:5678

Review-Url: https://codereview.chromium.org/2539123002
Cr-Commit-Position: refs/heads/master@{#41645}

Revert of [heap] Initialize the owner on each page after lospace allocation (patchset #2 id:20001 of https://codereview.chromium.org/2565713002/ )

Reason for revert:
Tree closer: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/12409

Original issue's description:
> [heap] Initialize the owner on each page after lospace allocation
>
> The least two bits of the owner field of a Page are used to determine
> whether the Page is part of a large object. If these bits are not equal
> to 0x11, the page is part of a large object and needs special handling
> e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it
> belongs to.
>
> This CL fixes an issue in which the store buffer overflows after
> a large object space allocation but before the object has been fully
> initialized. Store buffer overflow handling attempts to look up the
> chunk of a page, but fails to do so correctly since the page's owner
> field has not yet been initialized.
>
> This CL ensures that the owner field of all pages belonging to a large
> object allocation are initialized to a value that is interpreted
> correctly.
>
> BUG=chromium:672041
>
> Committed: https://crrev.com/9b6808bfb5366beebe3af30a06f9851edb2039d4
> Cr-Commit-Position: refs/heads/master@{#41641}

TBR=mlippautz@chromium.org,jgruber@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:672041

Review-Url: https://codereview.chromium.org/2562273004
Cr-Commit-Position: refs/heads/master@{#41644}

BUG=673240
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2565343002
Cr-Commit-Position: refs/heads/master@{#41643}

This CL moves all methods related to scripts and eval origin (HasScript,
GetScript, IsEval, GetEvalOrigin) from JSStackFrame to StackFrameBase,
because it also applies to WasmFrames.
This makes the AppendFileLocation method append the same information to
WasmStackFrames and AsmJsWasmStackFrames than to JSStackFrames.

R=titzer@chromium.org, mstarzinger@chromium.org
BUG=v8:4203

Review-Url: https://codereview.chromium.org/2557923005
Cr-Commit-Position: refs/heads/master@{#41642}

The least two bits of the owner field of a Page are used to determine
whether the Page is part of a large object. If these bits are not equal
to 0x11, the page is part of a large object and needs special handling
e.g. in MemoryChunk::FromAnyPointerAddress to determine which chunk it
belongs to.

This CL fixes an issue in which the store buffer overflows after
a large object space allocation but before the object has been fully
initialized. Store buffer overflow handling attempts to look up the
chunk of a page, but fails to do so correctly since the page's owner
field has not yet been initialized.

This CL ensures that the owner field of all pages belonging to a large
object allocation are initialized to a value that is interpreted
correctly.

BUG=chromium:672041

Review-Url: https://codereview.chromium.org/2565713002
Cr-Commit-Position: refs/heads/master@{#41641}

The current logic in Isolate::GetLocationFromStackTrace just ignores
wasm frames, making the computed location point to the first javascript
frame, like this:

test.js:17: RuntimeError: divide by zero
module.exports.main();
               ^
RuntimeError: divide by zero
    at main (<WASM>[1]+5)
    at test.js:17:16

This CL not only fixes the location to point to the top-most wasm
frame, but also exposes to the embedder that the script of that location
is a wasm script, allowing for custom printing of wasm locations.
The Shell::ReportException method now checks for this flag, and prints
wasm locations like this:

<WASM>[0]+5: RuntimeError: divide by zero
RuntimeError: divide by zero
    at main (<WASM>[0]+5)
    at test/message/wasm-trap.js:15:16

R=titzer@chromium.org, yangguo@chromium.org
BUG=chromium:613110

Review-Url: https://codereview.chromium.org/2563673002
Cr-Commit-Position: refs/heads/master@{#41640}

This only happens if there is a asm.js-wasm-frame on top of the stack
trace, which was not covered by our tests so far. The regression test
create a stack overflow in asm.js code, triggering this case.

R=mstarzinger@chromium.org
CC=titzer@chromium.org, bradnelson@chromium.org
BUG=chromium:673241

Review-Url: https://codereview.chromium.org/2562333002
Cr-Commit-Position: refs/heads/master@{#41639}

BUG=673240
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2568773002
Cr-Commit-Position: refs/heads/master@{#41638}

Review-Url: https://codereview.chromium.org/2558283002
Cr-Commit-Position: refs/heads/master@{#41637}

Add the operator in preparation for actual perf work. The operator is replaced
by the same runtime call as before, during lowering.

The CallConstructWithSpreadParameters is a bit silly at the moment, but will
hold more once we add feedback.

BUG=v8:5659

Review-Url: https://codereview.chromium.org/2561103003
Cr-Commit-Position: refs/heads/master@{#41636}

For generator-based functions (e.g. async functions) we force variables to be
context-allocated.  Due to a bug in the parser, this didn't always work
correctly.  For instance, in "async function foo([a]) { ... }" the variable "a"
could become stack-allocated due to context allocation being forced on the wrong
scope.

Besides fixing this, I'm also cleaning up some related code in the async parsing
setup and adding some guards.

R=adamk@chromium.org, littledan@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2561093002
Cr-Commit-Position: refs/heads/master@{#41635}

BUG=chromium:673244

Review-Url: https://codereview.chromium.org/2568053002
Cr-Commit-Position: refs/heads/master@{#41634}

The evaluation order of this argument was accidentally changed when the
special-case was added for super calls with a final spread argument.

Review-Url: https://codereview.chromium.org/2563423002
Cr-Commit-Position: refs/heads/master@{#41633}