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

BUG=

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

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

Renaming context confuses specialization passes. (And looking through
loop exit renames does not help because we insert Phis for SSA.)

BUG=chromium:635808

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

We only need these external v8 APIs to expose serialization externally,
so bypassed having an internal layer for now.

BUG=v8:5072

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

R=hpayer@chromium.org
BUG=chromium:612816,chromium:634900

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

For holey/growing keyed stores, we need to check that there are no
setters in the prototype chain and protect against changes to that
via code dependencies.

R=verwaest@chromium.org
BUG=v8:5275,v8:5276

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

Implement Bovc and Bnvc instruction macros in macro assembler.

The change 6f920d7d revealed an issue with AddBranchOvf for mips R6.
All branching instructions other than BOVC and BNVC are handled by Branch macro, which assures
correct handling of long and short branches. As a consequence, AddBranchOvf for R6 was working correctly
only before trampoline was emitted, but the case of long branch was not handled at all. Implemented
instruction macros enable proper handling of BOVC and BNVC in cases when long branching is needed.

TEST=test/intl/general/case-mapping.js

BUG=

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

This introduces initial support to handle keyed load access to
String primitives. This is accomplished via the existing operators
StringCharCodeAt and StringFromCharCode, which we already use to
optimize String.prototype.charCodeAt and String.fromCharCode.

R=yangguo@chromium.org
BUG=v8:5267

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

Rolling v8/build to e1fa1d72e5795ddcaff4ded5b083b1b08e52023a

Rolling v8/third_party/WebKit/Source/platform/inspector_protocol to eaa4c48e31e9f79fb6c4b665dc789dac0f0fb125

Rolling v8/third_party/icu to 53ce631655a61aaaa42b43b4d64abe23e9b8d71f

Rolling v8/tools/mb to d4f0973ff21ab990fed45c3803731c77197d65c8

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

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

Currently we have V8 RuntimeCallStats that is independently from tracing when
running d8 with flag --runtime_call_stats. This patch embeds V8 runtime call
stats into tracing, by having a global table of runtime call counters each
isolate, resetting the table each time we enter a top level trace event, and
dumping the table for each top level trace event. This will make trace file more
compat, as well as enable runtime call stats in tracing system.

This patch adds ~5% overhead to V8 when the category is enabled, we measure the
overhead by running a script when category is enabled.

BUG=v8:5089

Committed: https://crrev.com/d014866173eaa2b548c566217b2c94b1d49385fa
Committed: https://crrev.com/1ca3b73bba4a7253ca8eeef39321d70e7d414331
Committed: https://crrev.com/3f936a5b17754783e92d2146eaf66c88a78ee45b
Review-Url: https://codereview.chromium.org/2187693002
Cr-Original-Original-Original-Commit-Position: refs/heads/master@{#38270}
Cr-Original-Original-Commit-Position: refs/heads/master@{#38314}
Cr-Original-Commit-Position: refs/heads/master@{#38403}
Cr-Commit-Position: refs/heads/master@{#38510}

It can now deal with multiple objects at the same time (but no
aliasing), and it propagates store information upwards across effect
chain splits.

R=jarin
BUG=

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

BUG=v8:5209

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

This avoids direct scope() accesses and allows us to redirect it over ScopeState.

BUG=v8:5209

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

Remove the useless information from the BinaryOperationHints and
CompareOperationHints, and cache the JS operators appropriately.

R=epertoso@chromium.org

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

Block scopes don't need any special treatment here (it's unclear
to me why they ever did). And the has_forced_context_allocation() check
seems, according to our tests, to only have been necessary for proper
handling of 'with' scopes. This patch instead uses the "is_used" bit
to keep track of variables that are accessed from within a with.

R=neis@chromium.org

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

If a whole scope has forced context allocation, MustAllocateInContext()
already takes care of returning true for all variables, there's no need
to individually call ForceContextAllocation() on them.

R=neis@chromium.org

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

Because in case of interceptors we will install a slow stub that suits only one case.

BUG=chromium:634467
TBR=verwaest@chromium.org

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

R=danno,jarin
BUG=

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

Drive-by fix: Use  CodeStubAssembler::LoadNativeContext()

BUG=chromium:608675

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

BUG=

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

We assumed we could use a do..while, but the requested amount of slots could've
been 0 and we already started at MIN_CONTEXT_SLOTS. In that case the loop
should've been skipped.

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

Implementation of serialization/deserialization for compiled wasm
module.

BUG=v8:5072

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

This reverts commit d9d719e7.
Original review: https://codereview.chromium.org/2180273002/

With additional fixes to repair performance regressions:
- check PropertyCell::kValueOffset, not Cell::kValueOffset
- convert HeapNumbers to int on the fly if possible

NOPRESUBMIT=true

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

Drive-by-fix: mark isolates as const in stack-allocated scopes

BUG=chromium:630217

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

BUG=chromium:634900

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

R=machenbach@chromium.org

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

BUG=

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

On the debug info, we have a list of existing break points.  When we
step in the debugger, we flood the function with one-shot break points.
Afterwards, we clear these one-shots by clearing all break locations.

Previously, while clearing break locations, we would skip ones that have
actual break points. Now we clear all break locations, and then reapply
break points. This is necessary for the next step, when we encode break
point info by source position, and not code offset. Encoding by code
offset would mean that break points are dependent on the code kind we
use.

R=jgruber@chromium.org
BUG=v8:5265

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

When we compile a growing store in TurboFan, we don't pass a (native)
context to the %GrowArrayElements fallback function, as the whole logic
is actually context independent. However, that means that we need to
bailout early in case the object is a prototype, which requires context
dependent checks in the array protector code.

R=cbruni@chromium.org
BUG=chromium:635798

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

Revert of [heap] Enable black allocation when finalizing incremental marking. (patchset #1 id:1 of https://codereview.chromium.org/2224153003/ )

Reason for revert:
crashing on ToT

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

TBR=mlippautz@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/2223423003
Cr-Commit-Position: refs/heads/master@{#38490}

R=yangguo@chromium.org
TEST=cctest/test-serialize/CodeSerializerLargeCodeObject

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

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

BUG=chromium:630386

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

R=machenbach@chromium.org
NOTREECHECKS=true
NOTRY=true

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

Such scopes don't use those lists.

BUG=v8:5209

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

We lowered JSConvertReceiver using JSToObject, w/o connecting the
JSToObject to the control chain (which is fine since that ToObject
cannot throw). But then the lowering of the JSToObject would insert
an IfSuccess, which is immediately dead, since it is not used. This
was fine in a sense that it didn't seem to crash anything, but we
now want to do more aggressive checking if IfSuccess/IfException
nodes and so we need to fix this sloppyness in the lowerings.

R=mstarzinger@chromium.org

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

R=rmcilroy@chromium.org

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

BUG=v8:5265

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

BUG=chromium:634900

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