The flag has been on since at least Chrome 53.

R=littledan@chromium.org

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

R=adamk@chromium.org
BUG=v8:4806

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

This patch fixes two bugs in V8 to allow the global object to have a frozen proto:
- The immutable prototype map check is done on the map of the "real receiver",
  the one that's found after the hidden prototype traversal, rather than
  the object that SetPrototype is called on.
- The immutable prototype bit from the ObjectTemplate used to instantiate
  the global object, as passed to Context::New, is respected when instantiating
  the global object.

R=adamk
BUG=v8:5149

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

This patch is a follow-up patch to enable gc statistics to use
TracingCategoryObserver.

Previously we need to pass --track_gc_object_stats to v8 if we want to enable
gc statistics in tracing. In this patch, we introducce an integer flag
FLAG_gc_stats, and FLAG_track_gc_object_stats and FLAG_trace_gc_object_stats
will set it to 0x01, tracing will set it to 0x10 when we start tracing and
reset the bit when we stop tracing.

BUG=v8:5590

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

This removes the deprecated flag in question which has been enabled by
default a while ago. All components can by now deal with activations of
a single function being mixed between Ignition and other compilers. The
maintenance overhead to support a mode that clears bytecode is no longer
warranted.

R=rmcilroy@chromium.org
BUG=v8:4280

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

Compatible with the current (unshipped) Blink implementation.

BUG=chromium:148757

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

Port 9b308dca

R=jarin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com
BUG=

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

R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-662367
BUG=chromium:662367

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

If a HeapObject field is 8 bytes long and 8 bytes aligned, but we use only four bytes of it
on little endian architectures we will access to lower 4 bytes of the field using the same
base address as accessing the whole eight bytes
On big-endian architectures however we use base address to access the full 8 bytes, but base
address + 4 to access to lower 4 bytes. For this reason, the assert in OffsetForFieldAccess
fails on MIPS64 big endian.
We fix the issue by removing the assert that checks that offset is pointer size aligned.

TEST=mjsunit/regress/regress-crbug-648737
BUG=

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

Parameters of a lazily parsed function used to be parsed eagerly, and parameter
handling was split between Parser::ParseFunctionLiteral and
ParseEagerFunctionBody, leading to inconsistencies.

After this CL, we preparse (lazy parse) the parameters of lazily parsed
functions.

(For arrow functions, we cannot do that ofc.)

This is needed for later features (PreParser with scope analysis).

-- CL adapted from marja's https://codereview.chromium.org/2411793003/

BUG=

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

This was removed from ECMAScript in the September 2016 TC39 meeting, see https://github.com/tc39/ecma262/issues/670.

BUG=v8:5535

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

API was highly experimental. Embedders should use V8::RegisterExternalReference instead.

BUG=chromium:468240
R=jochen@chromium.org

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

The old code path is going to be removed with the debug context api.

R=kozyatinskiy@chromium.org

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

Reason for the failure is that the test enumeration is 32-bit wide, whereas
AtomicWord is 64-bit wide on 64-bit machines. On 64-big endian, this loads the random four bytes located after the 32-bit value that is tested.

BUG=
TEST=unittests/NoBarrierAtomicValue.Construction

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

- Remove (one version of) InterpreterAssembler::LoadContextSlot in favor of the
  identical CodeStubAssembler::LoadContextElement.
- Use CodeStubAssembler::LoadNativeContext instead of doing the load manually.

R=rmcilroy@chromium.org
BUG=

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

Some accessors requires little to no computation at all, its result can be
cached in a private property, avoiding the call overhead.
Calls to the getter are translated into a cheap property load.

Follow-on to crrev.com/2347523003, from peterssen@google.com

BUG=chromium:634276, v8:5548

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

Revert of [debugger] simplify fetching scripts for inspector. (patchset #6 id:100001 of https://codereview.chromium.org/2465833002/ )

Reason for revert:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/11118

Rule of thumb: As long as the tests have not migrated yet, you most certainly need a blink rebase whenever you change expectations.

Original issue's description:
> [debugger] simplify fetching scripts for inspector.
>
> The old code path is going to be removed with the debug context api.
>
> R=kozyatinskiy@chromium.org

TBR=kozyatinskiy@chromium.org,yangguo@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/2473273005
Cr-Commit-Position: refs/heads/master@{#40764}

Fix 4447405b

A typo in the patch caused failures on MIPS64. There were no failures on MIPS32,
but I guess the same patch needs to be applied there as well.

BUG=

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

Some cleanup after the cl to fix --trace-ic to work with ignition
(https://codereview.chromium.org/2405173007/). In GetSharedFunctionInfo,
we used to skip the bytecode handler frame, which is no longer required.

BUG=v8:4280

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

This is no longer necessary. Isolates created for serialization
have optimization disabled anyways.

R=jkummerow@chromium.org

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

When checking for marking a function for optimization, we had a check if
the function is already optimized to return early. This works in non-OSR
cases. For Turbofan OSR even when the current execution of the function
has already been optimized, the function itself will not be replaced
with optimized code. Hence, we may end up checking a function that is
already marked for optimization again. A check for the frame being optimized
avoids these checks.

BUG=

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

The old code path is going to be removed with the debug context api.

R=kozyatinskiy@chromium.org

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

Port f07d2cdd

Original commit message:
A load instruction will implicitely clear the top 32 bits when writing to a W
register. This patch avoids generating a `mov` instruction to zero-extend the
result in this case.

For example, this occurs in the generated code for dispatching to the next
bytecode in the interpreter:

  kind = BYTECODE_HANDLER
  name = LdaZero
  compiler = turbofan
  Instructions (size = 36)
  0x32e64c60     0  add x19, x19, #0x1 (1)
  0x32e64c64     4  ldrb w0, [x20, x19]
  0x32e64c68     8  mov w0, w0
                    ^^^^^^^^^^
  0x32e64c6c    12  lsl x0, x0, #3
  0x32e64c70    16  ldr x1, [x21, x0]
  0x32e64c74    20  movz x0, #0x0
  0x32e64c78    24  br x1

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

The value numbering reducer has collision checks for nodes that mutated,
but kept the same hash, and are now equivalent to another node. However,
it can also accidentally hit itself, if it mutated, changed hash, but
ran over the location it was previously in.

After this patch, it checks to see if it is comparing against itself,
and skips over itself. Additionally, if this check is at the end of the
collisions, it opportunistically removes the duplicate entry and reduces
the size pressure on the list. We can do the same opportunistic clean up
if we happen to find a colliding equivalent entry, since we move it from
its original position to a new one.

Drive-by change: Ensure that the collision replacement checks types in
the same way that normal replacement does.

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

R=ulan@chromium.org
BUG=

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

BUG=v8:5588
R=jochen@chromium.org

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

It always has the same number of slots.

R=adamk@chromium.org
TBR=bmeurer@chromium.org
BUG=v8:1569

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

- split up cctest/test-api/Threading*
- shortened mjsunit/math-floor-part*
- split up cctest/test-serialize/CustomSnapshotDataBlob
- skipped mjsunit/regress/regress-crbug-474297 unless gc-stress
- shortened cctest/test-serialize/CodeSerializerLargeCodeObject

R=jkummerow@chromium.org

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

Instead of having a MODULE variable's index be 0 or 1, let it be the index of
its cell.  In this CL, we assign the indices but we continue to only use them to
distinguish imports from exports.  Actually using them to directly access the
cells will be done in a later CL.

R=adamk@chromium.org
BUG=v8:1569

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

R=machenbach@chromium.org

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

BUG=v8:5598
TBR=adamk@chromium.org
NOTRY=true

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

TBR=jochen@chromium.org

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

This is how it would look like.

(gdb) bta
[1 ] V8_Fatal                                         ../../src/base/logging.cc:67
[2 ] v8::internal::Heap::AllocateRaw                  ../../src/heap/heap-inl.h:298
[3 ] v8::internal::Heap::AllocateHeapNumber           ../../src/heap/heap.cc:2432
[4 ] v8::internal::Factory::NewHeapNumber             ../../src/factory.cc:1253
[5 ] v8::internal::Factory::NewNumber                 ../../src/factory.cc:1228
[6 ] v8::internal::__RT_impl_Runtime_ConstructDouble  ../../src/runtime/runtime-test.cc:32
 -> Allow HEAP_ALLOCATION (yes_gc)
 -> Disallow HEAP_ALLOCATION (no_gc)
[7 ] v8::internal::Runtime_ConstructDouble            ../../src/runtime/runtime-test.cc:24

R=jochen@chromium.org

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

R=machenbach@chromium.org
BUG=v8:5457
NOTRY=true
NOTREECHECKS=true

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

Use a NumberConstant op rather than an Int32Constant to make assertions in
v8::internal::compiler::EscapeAnalysis::ProcessAllocation() happy.

BUG=v8:5598
R=bmeurer@chromium.org, franzih@chromium.org

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

This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.

BUG=v8:5590

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

BUG=none
R=dgozman@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

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

Revert of [Tracing] Use TracingCategoryObserver in runtime statistics (patchset #6 id:140001 of https://codereview.chromium.org/2460973003/ )

Reason for revert:
Static-Initializers failed on Ubuntu-12.04

Original issue's description:
> [Tracing] Use TracingCategoryObserver in runtime statistics
>
> This patch is a follow-up patch to enable runtime statistics to use
> TracingCategoryObserver.
>
> BUG=v8:5590

TBR=cbruni@chromium.org,fmeawad@chromium.org,alph@chromium.org,bmeurer@chromium.org,mlippautz@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5590

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

This patch is a follow-up patch to enable runtime statistics to use
TracingCategoryObserver.

BUG=v8:5590

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

Use HeapConstant for string_iterator_map rather than loading it
manually. This avoids unnecessary map checks.

BUG= v8:3822,v8:5267

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