Commit Graph

2008 Commits

Author SHA1 Message Date
Eric Holk
ee4fe8963c [wasm] trap handlers: fall back on old signal handler
This is primarily needed to test D8 under ASan. ASan installs a signal handler
early in the process startup to show stack traces from crashes. We need to make
sure that if V8 does not handle a signal then the existing handler gets a
chance.

This change only applies when using V8's default signal handler. When
integrating with the embedder's signal handler the behavior is unchanged.

Bug: chromium:771948
Change-Id: Ifd560acf9700ec5f714f009530258fa92c83cabe
Reviewed-on: https://chromium-review.googlesource.com/705823
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48429}
2017-10-10 18:03:12 +00:00
Michael Lippautz
b7e6eb9208 [heap] Introduce on-hold concurrent marking work list
When hitting objects that are allocated in the most recent lienar
allocation area, the concurrent marker currently has to bail out to the
main thread.

However, we only have to delay processing those objects until we are at
a safepoint, e.g. IM::Step(). With this change we flush those
on-hold-objects back to the shared queue upon performing an incremental
marking step.

Bug: chromium:694255
Change-Id: I25647d0fc581a5c4de0346bc394dc51062f65f70
Reviewed-on: https://chromium-review.googlesource.com/707315
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48424}
2017-10-10 11:33:39 +00:00
Andreas Haas
44c400eeaf [wasm] Fail upon second code section in streaming compilation
At the moment we check only in the module-decoder if the sections in a
module appear at most once. The code section, however, we process
already before this check. With this CL we check that there is at most
one code section before we start processing it.

R=clemensh@chromium.org
TEST=WasmStreamingDecoderTest.TwoCodeSections

Bug: chromium:771916
Change-Id: Icc79d5a87ab39f450a35c688f74ea5e67cae4b3c
Reviewed-on: https://chromium-review.googlesource.com/702379
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48314}
2017-10-05 15:11:02 +00:00
Toon Verwaest
1067026ff1 Remove ComputeFlags, simply pass in Code::Kind instead of Code::Flags
TBR: ofrobots@google.com, yangguo@chromium.org
Bug: 
Change-Id: I6cb0704acabf9a7f2334de539a6600db8607baef
Reviewed-on: https://chromium-review.googlesource.com/691720
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48237}
2017-09-29 15:37:27 +00:00
Marja Hölttä
fcb89f5515 [unicode] Add tests for UTF-8 decoders + minor cleanups.
Verify that both UTF-8 decoders (incremental and non-incremental one) match the
expectations.

Also cleanup / harden the UTF-8 handling code, as suggested in
https://chromium-review.googlesource.com/c/v8/v8/+/671020/ .


BUG=chromium:765608

Change-Id: I6344d62ca15b75ac8e333421c94c4aa35ab8190d
Reviewed-on: https://chromium-review.googlesource.com/681217
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48229}
2017-09-29 13:18:52 +00:00
Ross McIlroy
22e3211d9f [compiler] Remove script() from CompilationInfo
Removes script() from CompilationInfo since it might not be created when
compiling from a background thread.

BUG=v8:5203

Change-Id: Ic36fd04cf4792336707b2d3715d47c59b6a97faf
Reviewed-on: https://chromium-review.googlesource.com/690299
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48220}
2017-09-29 09:33:59 +00:00
Mostyn Bramley-Moore
d6ead37d26 [jumbo] add unittests jumbo support
TBR=jkummerow@chromium.org

Bug: chromium:746958
Change-Id: I7500b6206c4ceb087672de5b61b7e7ad234bb425
Reviewed-on: https://chromium-review.googlesource.com/690397
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48213}
2017-09-28 22:19:40 +00:00
Mircea Trofin
1cb0b9bf6a [wasm] Rename Release to Merge in the DisjointAllocationPool
Merge better captures the upcoming usecase in the wasm native heap,
where allocating/freeing is moving the accounting of memory from
a free list to an allocated list and vice-versa - making 'Release'
an odd API when allocating.

Bug: 
Change-Id: I9010959c91a1e8585eb06303ab06078132a03f60
Reviewed-on: https://chromium-review.googlesource.com/688004
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48211}
2017-09-28 17:24:22 +00:00
Enrico Bacis
6cd7a5a73a [wasm] Introduce the WasmContext
The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.

This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.

The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution.  The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.

This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).

R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org

Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
2017-09-28 16:14:03 +00:00
Peter Marshall
329f694678 [cleanup] Replace List with std::vector in api.
The members of HandleScopeImplementer are copied with memcpy when
the isolate is transferred to another thread. List contained some
primitives which allowed us to manually free the backing store, which
was needed in order to ensure that threads would not hold on to
old pointers and use them later. With std::vector, we can't do that.

Here we change the HandleScopeImplementer to instead use a custom
structure DetachableVector, which contains a std::vector but allows
manual detaching and freeing of the backing store. This allows us to
maintain the old behavior.

Bug: v8:6333
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
Reviewed-on: https://chromium-review.googlesource.com/660125
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48197}
2017-09-28 09:32:18 +00:00
Karl Schimpf
49106e4858 Add capability of throwing values in WASM
This is a second attempt at landing CL 644866 which was reverted by
CL 667019.

Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).

A JS typed (uint_16) array is used to hold the thrown values. This
allows all WASM types to be stored (i32, i64, f32, and f64) as well as
be inspected in JS.

The previous CL was reverted because the WASM compiler made calls to
run time functions with tagged objects, which must not be done. To fix
this, all run time calls use the thread-level isolate to hold the
exception being processed.

Bug: v8:6577
Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
Reviewed-on: https://chromium-review.googlesource.com/677056
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48148}
2017-09-25 16:58:19 +00:00
Benedikt Meurer
855b88ae5a [turbofan] Properly optimize literals in inlined functions.
When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.

The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from

  createEmptyArrayLiteral: 1846 ms.
  createShallowArrayLiteral: 1868 ms.
  createShallowObjectLiteral: 2246 ms.

to

  createEmptyArrayLiteral: 1175 ms.
  createShallowArrayLiteral: 1187 ms.
  createShallowObjectLiteral: 1195 ms.

with this CL, so up to 2x faster now.

Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.

Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
2017-09-25 13:05:16 +00:00
Clemens Hammacher
7ed27c474a [cleanup] [compiler] Fix (D)CHECK macros
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.

This will allow us to reenable the readability/check cpplint check.

R=jarin@chromium.org

Bug: v8:6837
Change-Id: I712580c2a4326e06ee3d6d0eb4ff8c7d24f5fdb9
Reviewed-on: https://chromium-review.googlesource.com/671227
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48135}
2017-09-25 10:21:34 +00:00
Benedikt Meurer
79ac69b83c [es2015] Introduce dedicated GetTemplateObject bytecode.
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).

This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.

With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from

  templateStringTagES5: 4552 ms.
  templateStringTagES6: 14185 ms.
  templateStringTagBabel: 7626 ms.

to

  templateStringTagES5: 4515 ms.
  templateStringTagES6: 7491 ms.
  templateStringTagBabel: 7639 ms.

which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.

Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
2017-09-22 19:52:30 +00:00
Bill Budge
d607f1e72d [Memory] Move GetRandomMmapAddr from base::OS platform to v8::internal.
- Moves GetRandomMmapAddr from platform to v8::internal allocation
  primitives, in preparation for delegating this to the embedder.
- Adds hint parameters to OS functions that used to use this function.

Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iad72e6eac9c08a3e22c2cd2b2905623b8e514ae0
Reviewed-on: https://chromium-review.googlesource.com/677777
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48124}
2017-09-22 15:26:18 +00:00
Clemens Hammacher
3a06391166 [base] Allow comparing enums in (D)CHECKs
In the current implementation, compilation would fail because
operator<< is not defined for enum classes. For others, the compiler
finds more than one operator<<, so it fails because it's ambiguous.

This CL fixes this by printing the integer value for enums, uses the
operator<< for all values that support it, and prints "<unprintable>"
otherwise.

Also, lots of unit tests.

R=ishell@chromium.org

Bug: v8:6837
Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4
Reviewed-on: https://chromium-review.googlesource.com/671016
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48110}
2017-09-21 13:33:30 +00:00
Clemens Hammacher
008d7b2ad2 [wasm] Remove redundant validation
And add some tests for (seemingly) previously uncovered cases.
The additional check for unreachable code is not needed any more, since
polymorphic stack values get assigned a specific type on their first
use or validation anyway. Hence the first entry in the br_table will
assign specific types to all polymorphic stack values, and type checking
will fail if later entries do not match.

R=rossberg@chromium.org
CC=titzer@chromium.org

Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7
Reviewed-on: https://chromium-review.googlesource.com/675405
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48109}
2017-09-21 13:30:00 +00:00
Michael Lippautz
4e5db9a6c8 [heap] Remove marking deque overflow handling
Removes
- SequentialMarkingDeque
- The ability to handle marking deque overflow
- BlackToGrey transitions

We switched to a different marking work list on M61 that fails
in OOM upon failing to allocate Segments used in the work list.

Bug: chromium:758570
Change-Id: I66e2ab912271bf84b085dccc9b4bdd96076b64fb
Reviewed-on: https://chromium-review.googlesource.com/632676
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48078}
2017-09-19 05:20:20 +00:00
Mircea Trofin
3d046986f0 Revert "Revert "[wasm] A simple allocator datastructure for off-the heap""
This reverts commit ee5c31f335.

Reason for revert: Fixed compiler failure

Original change's description:
> Revert "[wasm] A simple allocator datastructure for off-the heap"
> 
> This reverts commit 110d9ab005.
> 
> Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
> 
> Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
> 
> Original change's description:
> > [wasm] A simple allocator datastructure for off-the heap
> > 
> > We'll use this allocator in a follow-up CL to:
> > - allocate speculative sizes of memory for a module that's being
> > compiled (e.g. 2*size of wasm code).
> > - each module will own such a sub-pool, and then use it to allocate
> > contiguous chunks of memory for code.
> > 
> > The underlying assumptions for the chosen allocation strategy is that:
> > - the allocation granularity for pools is 1 page, so that no one page
> > is owned by more than one wasm module
> > - typical pool sizes (given module sizes) are multiple pages.
> > - modules and module instances are typically few and long lived. Typically,
> > we expect one module and one instance. 
> > 
> > This means we shouldn't expect fragmentations that lead to code being
> > non-allocatable, or prohibitively many ranges.
> > 
> > The data structure just manages ranges of addresses. Virtual memory management
> > will be separate, as part of the responsibility of a "WasmHeap"
> > that will be introduced in the future. So will concurrency control.
> > 
> > Bug: 
> > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> > Reviewed-on: https://chromium-review.googlesource.com/669296
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Eric Holk <eholk@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48053}
> 
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
> 
> Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/670141
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48054}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670142
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48055}
2017-09-16 05:23:35 +00:00
Mircea Trofin
ee5c31f335 Revert "[wasm] A simple allocator datastructure for off-the heap"
This reverts commit 110d9ab005.

Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607

Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?

Original change's description:
> [wasm] A simple allocator datastructure for off-the heap
> 
> We'll use this allocator in a follow-up CL to:
> - allocate speculative sizes of memory for a module that's being
> compiled (e.g. 2*size of wasm code).
> - each module will own such a sub-pool, and then use it to allocate
> contiguous chunks of memory for code.
> 
> The underlying assumptions for the chosen allocation strategy is that:
> - the allocation granularity for pools is 1 page, so that no one page
> is owned by more than one wasm module
> - typical pool sizes (given module sizes) are multiple pages.
> - modules and module instances are typically few and long lived. Typically,
> we expect one module and one instance. 
> 
> This means we shouldn't expect fragmentations that lead to code being
> non-allocatable, or prohibitively many ranges.
> 
> The data structure just manages ranges of addresses. Virtual memory management
> will be separate, as part of the responsibility of a "WasmHeap"
> that will be introduced in the future. So will concurrency control.
> 
> Bug: 
> Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> Reviewed-on: https://chromium-review.googlesource.com/669296
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48053}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org

Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670141
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48054}
2017-09-16 05:11:24 +00:00
Mircea Trofin
110d9ab005 [wasm] A simple allocator datastructure for off-the heap
We'll use this allocator in a follow-up CL to:
- allocate speculative sizes of memory for a module that's being
compiled (e.g. 2*size of wasm code).
- each module will own such a sub-pool, and then use it to allocate
contiguous chunks of memory for code.

The underlying assumptions for the chosen allocation strategy is that:
- the allocation granularity for pools is 1 page, so that no one page
is owned by more than one wasm module
- typical pool sizes (given module sizes) are multiple pages.
- modules and module instances are typically few and long lived. Typically,
we expect one module and one instance. 

This means we shouldn't expect fragmentations that lead to code being
non-allocatable, or prohibitively many ranges.

The data structure just manages ranges of addresses. Virtual memory management
will be separate, as part of the responsibility of a "WasmHeap"
that will be introduced in the future. So will concurrency control.

Bug: 
Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
Reviewed-on: https://chromium-review.googlesource.com/669296
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48053}
2017-09-16 04:53:11 +00:00
Camillo Bruni
28620d1929 Revert "Add capability of throwing values in WASM"
This reverts commit 7b5a40222e.

Reason for revert: GC stress-test failures exposed by 7742e534a8
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15110/steps/Mjsunit/logs/exceptions


Original change's description:
> Add capability of throwing values in WASM
> 
> Extends the current implementation of WASM exceptions to be able to
> throw exceptions with values (not just tags).
> 
> An JS typed array (uint_16) is used to hold thrown values, so that the
> thrown values can be inspected in JS.
> 
> Bug: v8:6577
> Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
> Reviewed-on: https://chromium-review.googlesource.com/633866
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48001}

TBR=bbudge@chromium.org,mtrofin@chromium.org,eholk@chromium.org,clemensh@chromium.org,kschimpf@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: v8:6577
Change-Id: I8f545183c2d2abb1bf4a0b3ee23379f3754ffd55
Reviewed-on: https://chromium-review.googlesource.com/667019
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48050}
2017-09-15 20:27:39 +00:00
Sigurdur Asgeirsson
a787c3f9e1 Allow overriding DCHECK handling and make it non-fatal.
Bug: chromium:763010
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I7d479f8abb16ffd7ffc19d3a6b58da01f5feddd0
Reviewed-on: https://chromium-review.googlesource.com/661054
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Sigurður Ásgeirsson <siggi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48038}
2017-09-15 11:48:16 +00:00
Andreas Haas
549692cbc0 [wasm] Streaming compilation for WebAssembly.
In this CL I implement streaming compilation for WebAssembly,
as described in the design doc I have sent out already.

In this implementation the decoding of sections other than the
code section is done immediately on the foreground thread.
Eventually all decoding should happen in the background. I
think it is acceptable to do the decoding on the foreground
thread for now because I have finished it already, and
decoding in the background would add even more complexity to
this CL.

Bug:v8:6785

Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I285e1e5e1a5a243113c92571b25ee9bae551d0ed
Reviewed-on: https://chromium-review.googlesource.com/631721
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48022}
2017-09-15 06:36:25 +00:00
Jaideep Bajwa
b1cd08daf7 PPC/s390: [iwyu] Remove illegal inline include from "macro-assembler.h"
Port bc69f3450b

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I88f0167a43fb7eb7967169a84466de3aedf00125
Reviewed-on: https://chromium-review.googlesource.com/666299
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48014}
2017-09-14 12:23:51 +00:00
Karl Schimpf
7b5a40222e Add capability of throwing values in WASM
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).

An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.

Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
2017-09-13 19:29:15 +00:00
Michael Starzinger
bc69f3450b [iwyu] Remove illegal inline include from "macro-assembler.h"
R=clemensh@chromium.org

Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I3df5d50f81909188ee0cb31d0f479aadeeabe20f
Reviewed-on: https://chromium-review.googlesource.com/662780
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47991}
2017-09-13 11:44:07 +00:00
Adam Klein
c9efff3fcd [bigint] Add bytecodes for unary-minus and bitwise-not
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.

Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
2017-09-12 19:07:59 +00:00
Adam Klein
bf55951cdd [bigint] Output ToNumber bytecode for unary plus
As part of that change, make ToNumber return in the accumulator.

Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
2017-09-12 15:27:21 +00:00
pan.deng@intel.com
d8864701fd [csa] Add constant folding more universally to CodeAssembler operators
Contributed by kanghua.yu@intel.com.

Bug: None
Change-Id: I5651ef38eb0c08deb97770a5eaa985dba2dab9a9
Reviewed-on: https://chromium-review.googlesource.com/604648
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Pan Deng <pan.deng@intel.com>
Cr-Commit-Position: refs/heads/master@{#47968}
2017-09-12 10:03:10 +00:00
Mike Stanton
8340a86a62 Remove Code::FUNCTION type and predicates.
Since we don't have a full-codegen compiler anymore, we no longer
generate Code::FUNCTION kind. Nice! Here is some cleanup.

Bug: v8:6409
Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762
Reviewed-on: https://chromium-review.googlesource.com/657817
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47951}
2017-09-11 14:57:57 +00:00
Clemens Hammacher
f9efb571ab [wasm] [test] [cleanup] Add missing undefs
Cleanup before enabling the presubmit check:
https://chromium-review.googlesource.com/c/v8/v8/+/657104

Bug: v8:6811
R=ahaas@chromium.org
CC=​​mstarzinger@chromium.org

Change-Id: Ifbf9210464b46dfdb5e04fbedc41d30e11536f74
Reviewed-on: https://chromium-review.googlesource.com/657422
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47943}
2017-09-11 12:09:50 +00:00
Jaroslav Sevcik
6e8c00f7df Introduce an Abort bytecode and turbofan operator.
The advantage of an explicit Abort that the interpreter and the compiler know
that aborting cannot continue or throw or deopt. As a result we generate less
code and we do not confuse the compiler if the environment is not set up for
throwing (as in the generator dispatch that fails validation in
crbug.com/762057).

Bug: chromium:762057
Change-Id: I3e88f78be32f31ac49b1845595255f802c405ed7
Reviewed-on: https://chromium-review.googlesource.com/657025
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47922}
2017-09-08 12:16:23 +00:00
Franziska Hinkelmann
335c8ad009 [type-profile] Incorporate into inspector protocol.
JavaScript is a dynamically typed language. But most code is 
written with fixed types in mind. When debugging JavaScript, 
it is helpful to know the types of variables and parameters 
at runtime. It is often hard to infer types for complex code. 
Type profiling provides this information at runtime.

Node.js uses the inspector protocol. This CL allows Node.js users 
to access and analyse type profile for via Node modules or the
in-procress api. Type Profile helps developers to analyze 
their code for correctness and performance.  

Design doc: https://docs.google.com/a/google.com/document/d/1O1uepXZXBI6IwiawTrYC3ohhiNgzkyTdjn3R8ysbYgk/edit?usp=sharing

Add `takeTypeProfile` to the inspector protocol. It returns a list
of TypeProfileForScripts, which in turn contains the type profile for
each function. We can use TypeProfile data to annotate JavaScript code. 

Sample script with data from TypeProfile:
function f(/*Object, number, undefined*/a, 
           /*Array, number, null*/b, 
           /*boolean, Object, symbol*/c) {
  return 'bye';
/*string*/};
f({}, [], true);
f(3, 2.3, {a: 42});
f(undefined, null, Symbol('hello'));/*string*/

Bug: v8:5933
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I626bfb886b752f90b9c86cc6953601558b18b60d
Reviewed-on: https://chromium-review.googlesource.com/508588
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47920}
2017-09-08 09:46:12 +00:00
Toon Verwaest
04419d4d89 [builtins] Migrate the Object constructor from JS to CSA.
This speeds up the baseline performance of Object by 20%.

With this change, the callViaObject when run with --noopt
goes from 10718ms to 8577ms on the benchmark from:
http://benediktmeurer.de/2017/08/31/object-constructor-calls-in-webpack-bundles

Bug: v8:6772
Change-Id: Id0e54ba44204a1700885185ec360e1c56834fb73
Reviewed-on: https://chromium-review.googlesource.com/654900
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47888}
2017-09-07 14:38:32 +00:00
Yang Guo
d4c6c7561c [heap] remove heap init from shipping binary.
This reduces the arm32 binary by around 20kB.

R=jkummerow@chromium.org, mstarzinger@chromium.org

Bug: v8:6055
Change-Id: If9098e49793b29dceb8292aff6f668ca28a07728
Reviewed-on: https://chromium-review.googlesource.com/652427
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47863}
2017-09-07 05:24:49 +00:00
Jaroslav Sevcik
095de95be1 [interpreter] printing: output the native context index as string
Bug: 
Change-Id: Iedd273d517e2ee2e548a5e9732689114800e6128
Reviewed-on: https://chromium-review.googlesource.com/649749
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47822}
2017-09-05 12:57:09 +00:00
Michael Starzinger
e461e1c646 [presubmit] Enable and fix "build/namespaces" linter check.
R=clemensh@chromium.org

Change-Id: I42241713b7d14dd1cb321df0570566b0873c10a4
Reviewed-on: https://chromium-review.googlesource.com/647888
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47793}
2017-09-04 11:24:26 +00:00
Clemens Hammacher
57375079cd [wasm] Remove 'using namespace' from cctest/wasm
This required splitting wasm-run-utils.h in header and implementation,
since the anonymous namespace in wasm-run-utils.h is now gone.
This is a reasonable refactoring in itself.

R=titzer@chromium.org
CC=mstarzinger@chromium.org, mostynb@opera.com

Bug: chromium:746958
Change-Id: I0f3b30fef1865cd88eca37b69d0c3a9eb19e77ea
Reviewed-on: https://chromium-review.googlesource.com/647587
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47773}
2017-09-01 13:49:24 +00:00
Benedikt Meurer
f1ec44e2f5 [turbofan] Optimize fast enum cache driven for..in.
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like

  for (var k in o) {
    var v = o[k];
    // ...
  }

and code like

  for (var k in o) {
    if (Object.prototype.hasOwnProperty.call(o, k)) {
      var v = o[k];
      // ...
    }
  }

which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.

For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:

 forIn: 1516 ms.
 forInHasOwnProperty: 1674 ms.
 forInHasOwnPropertySafe: 1595 ms.
 forInSum: 2051 ms.
 forInSumSafe: 2215 ms.

Compared to numbers from V8 5.8 which is the last version running with
Crankshaft

 forIn: 1641 ms.
 forInHasOwnProperty: 1719 ms.
 forInHasOwnPropertySafe: 1802 ms.
 forInSum: 2226 ms.
 forInSumSafe: 2409 ms.

and V8 6.0 which is the current stable version with TurboFan:

 forIn: 1713 ms.
 forInHasOwnProperty: 5417 ms.
 forInHasOwnPropertySafe: 5324 ms.
 forInSum: 7556 ms.
 forInSumSafe: 11067 ms.

It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.

For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.

This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.

Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
2017-09-01 11:27:37 +00:00
Jaroslav Sevcik
b1c1228981 [turbofan] Fix arm backend matching of (x >>> 24) & 0xffff.
We emitted rotation by 24 bits with bitwise and, but that is wrong
because the low 8 bits can wrap around and "leak" into the result.

Bug: chromium:739902
Change-Id: Id49251e89405afb1581b8c60cde808c2d8bf693d
Reviewed-on: https://chromium-review.googlesource.com/645848
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47746}
2017-08-31 13:50:07 +00:00
Michael Starzinger
02fdbcc05f [turbofan] Avoid disallowed "using namespace" directive.
R=leszeks@chromium.org

Change-Id: Iae67b6b81459304192c81b1367a11fba076c7512
Reviewed-on: https://chromium-review.googlesource.com/645630
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47741}
2017-08-31 11:52:15 +00:00
Michael Lippautz
9619b7f23c [heap] Factor out the barrier from Scavenger and add tests
Bug: chromium:738865, chromium:750084
Change-Id: Ife30da4be118cd6f3212e84752978ebb39500f15
Reviewed-on: https://chromium-review.googlesource.com/641414
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47710}
2017-08-30 12:05:56 +00:00
Ben L. Titzer
c48f40d0d9 [wasm] Decoder should narrow unreachable types on the stack.
R=rossberg@chromium.org

Bug: v8:6651
Change-Id: Iaa9217cacded9bdd3f0a35775275e79c231c272a
Reviewed-on: https://chromium-review.googlesource.com/642969
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47709}
2017-08-30 11:49:16 +00:00
Peter Marshall
2261a0ddf6 [cleanup] Replace List with std::vector in IC, Handle code.
Bug: v8:6333
Change-Id: I53d321292b0a2c7b7f72ee90bd119484f163bdc1
Reviewed-on: https://chromium-review.googlesource.com/637913
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47701}
2017-08-30 07:35:00 +00:00
Sergei D
11ba497cd8 Delegate getting current wall-clock time to the Platform interface.
To enable executing code in a context of a particular time or date (e.g. when
codepath depends on whether it's say evening or New Year) there is a need for
a way to provide it bypassing actual system time.

Bug: chromium:751993
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iee35d97b74345f63fff814a65a6f134d7c970341
Reviewed-on: https://chromium-review.googlesource.com/598666
Commit-Queue: Sergei Datsenko <dats@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47700}
2017-08-30 06:28:09 +00:00
Tobias Tebbi
46473f827f [turbofan] delete old implementation of escape analysis
Bug: 
Change-Id: Ib9e0d0844ad5e7bc6cd038f736546cad77669321
Reviewed-on: https://chromium-review.googlesource.com/641530
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47699}
2017-08-30 06:03:29 +00:00
Adam Klein
ce05578aa6 [api] Mark non-Isolate constructors of String::Utf8Value/Value for deprecation
Also remove last internal callers of the to-be-deprecated APIs.

Bug: v8:2487
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Id72cf363eac86e4b4dbf7df83bdb848071260b90
Reviewed-on: https://chromium-review.googlesource.com/639326
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47690}
2017-08-29 17:42:34 +00:00
Clemens Hammacher
54040fff71 Reland "[wasm] Refactor function body decoder"
This is a reland of 6b4dc039a6
Original change's description:
> [wasm] Refactor function body decoder
> 
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
> 
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
> 
> R=titzer@chromium.org
> 
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}

TBR=titzer@chromium.org

Bug: v8:6600
Change-Id: Idd867c5a1917437de5b6e3de5917cc1c9f194489
Reviewed-on: https://chromium-review.googlesource.com/640591
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47678}
2017-08-29 11:56:17 +00:00
Clemens Hammacher
425ede39eb Revert "[wasm] Refactor function body decoder"
This reverts commit 6b4dc039a6.

Reason for revert: Mips build failure: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/11749

Original change's description:
> [wasm] Refactor function body decoder
> 
> This refactoring separates graph building from wasm decoding. The
> WasmGraphBuilder is just a consumer of the decoded information.
> Decoding without any consumer (i.e. just validation) gets 16% faster by
> this refactoring, because no TFNode* have to be stored in the value
> stack, and all dynamic tests to determine whether the graph should be
> build are gone (measured on AngryBots; before: 110.2 +- 3.3ms, after:
> 92.2 +- 3.1 ms).
> 
> This new design will allow us to also attach other consumers, e.g. a
> new baseline compiler.
> 
> R=​titzer@chromium.org
> 
> Bug: v8:6600
> Change-Id: I4b60f2409d871a16c3c52a37e515bcfb9dbb8f54
> Reviewed-on: https://chromium-review.googlesource.com/571010
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47671}

TBR=titzer@chromium.org,clemensh@chromium.org

Change-Id: I76a50e355f0390cc53a2da4ceedd8830ca20a9c6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600
Reviewed-on: https://chromium-review.googlesource.com/640870
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47672}
2017-08-29 10:45:30 +00:00