Commit Graph

10832 Commits

Author SHA1 Message Date
Ben Smith
9010424ff5 Reland "[wasm] Implement table.init for interpreter"
This is a reland of 63608968b6

The previous CL failed on Windows, but it was a general bug. The
dropped_elem_segments was not being set on the instance properly in
cctests, so`table.init` instructions would fail by reading uninitialized
data.

I took this opportunity to also add an implementation of
`elem.drop` in the interpreter, and ported the JS tests for those too.

Original change's description:
> [wasm] Implement table.init for interpreter
>
> This also fixes CheckCallViaJS when a trap occurs. In that case, the
> trap callback is called instead of an exception being thrown, so if it
> isn't handled, a bogus result will be returned instead.
>
> Bug: v8:8965
> Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Smith <binji@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60473}

Bug: v8:8965
Change-Id: Ia547d9530b7ca67fde5bd94539f49153b796e82d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547142
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60664}
2019-04-05 20:09:33 +00:00
Michael Starzinger
2b7fdbfc75 [wasm] Fix lifetime of reference values on interpreter stack.
This ensures the lifetime of reference values on the simulated operand
stack of the interpreter is coupled to a lifetime of the {ThreadImpl}.
We no longer directly store reference values on the stack, but maintain
a separate "reference stack" on the GC'ed heap. This will ensure the GC
traces such references properly.

The new {StackValue} safety wrapper makes sure all use-sites that access
the operand stack properly convert to/from handles when dealing with
reference values.

R=clemensh@chromium.org
TEST=mjsunit/wasm/exceptions-interpreter
BUG=v8:8091,v8:7581

Change-Id: I8c05f2d945a6def943b89be0cfca538a73df8855
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552791
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60650}
2019-04-05 12:47:56 +00:00
Frederik Gossen
fa7c0ed288 [wasm-hints] Resolve Performance Problem
Locks for compilation state callbacks and for the native module are
again taken one after the other. As a consequence, publishing compiled
Wasm code again happens in parallel. Compile times are now comparable to
before lazy hints were enabled.

Bug: chromium:949050
Change-Id: I45c52254d046de080938bd131fd3ed8116660bef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1552787
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60646}
2019-04-05 11:07:00 +00:00
Daniel Clifford
62a3280563 [torque] Indexed class field initialization
Indexed fields in classes can now be initialized using iterators
and a spread syntax, e.g.:

  class Foo {
    length: Smi;
    elements[length]: Object;
  }

  new Foo{length: 5, elements: ...iter};

where iter implements Torque's iterator protocol. This protocol
requires the definition of a method with the following signature:

  Next(): <type> labels NoMore;

Where <type> is the Torque type of the values to be iterated.
In the case of indexed field initialization, the type must be
the field's type or a subtype thereof.

Field initialization with spread is desugared into a loop that
calls the spread iterator's Next method and assigns each
returned value in order to the corresponding indexed field
element.

The general machinery for the spread syntax has been added to
the ast and parser, however, it can currently only be used in
the specific context of indexed field initialization. Spread
operators used in any other context will cause an error.

Bug: v8:7793
Change-Id: If071e61db8166573c28d13318879c88ba96f6d98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550407
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60639}
2019-04-04 17:58:59 +00:00
Sigurd Schneider
75ae54c55b [cctest] Add V8_EXPORT_PRIVATE for cctest (objects part)
Bug: v8:9020

Change-Id: I1b9f3c0c805709c6570785ec9f1045f21c9d03e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541048
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60638}
2019-04-04 14:32:38 +00:00
Frank Tang
bb24140cb3 [Intl] Cutting 43K by removing Unibrow when ICU available
Making 43K of room for landing ICU64.

Size Change (on x64.release)
D8 before 23,683,192
D8 after 23,639,296
Reduce 43,896 bytes

Bugs: v8:8348

Change-Id: I057f7d59e955a2e5e017873e5b3b5daf5b142ae2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1478710
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60616}
2019-04-03 17:58:51 +00:00
Frederik Gossen
be83fea988 [wasm-hints] Merged Tier Enum
Merged WasmCode::Tier into Execution Tier.

Bug: v8:9003
Change-Id: I0ad439b8bc060f73e71d60ab9c93dd6bc18d05fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547852
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60610}
2019-04-03 16:13:21 +00:00
Clemens Hammacher
084207d968 [wasm] Use engine's allocator consistently
Using the Isolate's allocator when creating the WasmModule can lead to
use-after-free situations when the NativeModule is shared across
Isolates.

R=mstarzinger@chromium.org

Bug: v8:9079
Change-Id: I5a564852179cc5b9d4cbad2a002d3b6e14b01968
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550404
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60605}
2019-04-03 14:33:30 +00:00
Michael Starzinger
46a99b07fc [wasm] Add support for "br_on_exn" in the interpreter.
This adds preliminary support for handling the "br_on_exn" opcode in the
interpreter. It also makes "catch" and "rethrow" use a proper exception
reference instead of a dummy value.

To that end this also adds {Handle<>} as a new kind of {WasmValue} which
is intended to pass reference values (e.g. "anyref" or "except_ref") to
the runtime system. Therefore lifetime of such a {WasmValue} is directly
coupled to any surrounding {HandleScope}.

For now we just store {Handle<>} directly on the simulated operand stack
of the interpreter. This is of course bogus, since the surrounding scope
does not outlive the interpreter activation. Decoupling the lifetime of
the operand stack from a {HandleScope} will be done in a follow-up CL.

As a drive-by this change also implements support for the "ref_null" and
the "ref_is_null" opcodes as a proof-of-concept that the new {WasmValue}
is also applicable to the "anyref" reference type.

R=clemensh@chromium.org
TEST=cctest/test-run-wasm-interpreter/ReferenceTypeLocals
BUG=v8:8091,v8:7581

Change-Id: I2307e0689a19c4aab1d67f1ba6742cb3cc31aa3c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550299
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60598}
2019-04-03 12:16:36 +00:00
Maciej Goszczycki
ead412ecde [cleanup] Use CHECK_EQ in test-heap-profiler.cc where possible
Bug: v8:8834
Change-Id: Iac747d915f50c64bb91ca7b8365a51d96eacd2ed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1549161
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Maciej Goszczycki <goszczycki@google.com>
Cr-Commit-Position: refs/heads/master@{#60596}
2019-04-03 11:54:06 +00:00
Andrew Comminos
8bedd29166 [cpu-profiler] Add SourceType field to CpuProfileNode
Adds the notion of a "source type" to CpuProfileNode instances, hinting
at the underlying source of the function or state that resulted in the
generation of the node.

Bug: v8:9001
Change-Id: Ie14c54d41b99eb02f54b423fa5d939e9d7f63785
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1510576
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60590}
2019-04-03 10:35:03 +00:00
Santiago Aboy Solanes
70b2216240 [Turbofan][ptr-compr] Add representation changes for and to Compressed* values
Includes both changing from compressed pointers and to compressed pointers.

Also added tests to the representation changer test

B

Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng,v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977
Change-Id: I8a13f6b7ec2208442aa354949173cc9061bce168
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533866
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60587}
2019-04-03 09:45:53 +00:00
Paolo Severini
969cb0c7a5 Reland "V8 x64 backend doesn't emit ABI compliant stack frames"
This is a reland of 3cda21de77

Original change's description:
> V8 x64 backend doesn't emit ABI compliant stack frames
> 
> On 64 bit Windows, the OS stack walking does not work because the V8 x64
> backend doesn't emit unwinding info and also because it doesn't emit ABI
> compliant stack frames. See
> https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
> for more details.
> 
> This problem can be fixed by observing that V8 frames usually all have the same
> prolog and epilog:
> 
> push rbp,
> mov rbp, rsp
> ...
> pop rbp
> ret N
> 
> and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
> should walk through V8 frames. Furthermore, since V8 Code objects are all
> allocated in the same code-range for an Isolate, it is possible to register a
> single PDATA/XDATA entry to cover stack walking for all the code generated
> inside that code-range.
> 
> This PR contains changes required to enable stack walking on Win64:
> 
> EmbeddedFileWriter now adds assembler directives to the builtins
> snapshot source file (embedded.cc) to emit additional entries in the .pdata and
> in the .xdata section of the V8 executable. This takes care of stack walking
> for embedded builtins. (The case of non-embedded builtins is not supported).
> The x64 Assembler has been modified to collect the information required to emit
> this unwind info for builtins.
> 
> Stack walking for jitted code is handled is Isolate.cpp, by registering
> dynamically PDATA/XDATA for the whole code-range address space every time a new
> Isolate is initialized, and by unregistering them when the Isolate is
> destroyed.
> 
> Stack walking for WASM jitted code is handled is the same way in
> wasm::NativeModule (wasm/wasm-code-manager.cpp).
> 
> It is important to note that Crashpad and Breakpad are already registering
> PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
> builtins). Since it is not possible to register multiple PDATA entries for the
> same address range, a new function is added to the V8 API:
> SetUnhandledExceptionCallback() can be used by an embedder to register its own
> unhandled exception handler for exceptions that arise in v8-generated code.
> V8 embedders should be modified accordingly (code for this is in a separate PR
> in the Chromium repository:
> https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
> 
> All these changes are experimental, behind:
> 
> the 'v8_win64_unwinding_info' build flag, and
> the '--win64-unwinding-info' runtime flag.
> 
> Bug: v8:3598
> Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#60330}

Bug: v8:3598
Change-Id: If988baf7d3e4af165b919d6e54c1ad985f8e25e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534618
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#60581}
2019-04-03 02:00:43 +00:00
Clemens Hammacher
d4266e3035 [wasm][gc] Add code ref scopes for code GC
This CL adds all the necessary {WasmCodeRefScope}s in the code base, or
at least a good approximation. A follow-up CL will enable a check that
a {WasmCodeRefScope} exists whenever a pointer to a {WasmCode} object
is returned from the {NativeModule}. This should flush out any missing
scopes.

R=titzer@chromium.org

Bug: v8:8217
Change-Id: I54c7eb39aeb1acde38273c399396e6b1390a4cb2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1533860
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60566}
2019-04-02 11:37:41 +00:00
Frederik Gossen
9ac3ec565d Reland "[wasm-hints] Enabled Lazy Compilation by Hint"
This is a reland of 09fa63a935

Original change's description:
> [wasm-hints] Enabled Lazy Compilation by Hint
>
> Hints for lazy compilation are now taken into consideration. If the
> custom hints section suggests lazy compilatin we do so unless the module
> consists of a single function.
>
> Bug: v8:9003
> Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
> Commit-Queue: Frederik Gossen <frgossen@google.com>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60557}

Bug: v8:9003
No-Try: true
Change-Id: I8d6f4518aa548c815fba4e6e62d2206129336cc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547851
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60564}
2019-04-02 10:31:22 +00:00
Daniel Clifford
9fe209bd4a Reactivate Torque cctest tests
Change-Id: I873a8a53f93d0b43d18f6dbc620a2fa3f4b30d32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547850
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60561}
2019-04-01 19:38:51 +00:00
Frederik Gossen
be470c5546 Revert "[wasm-hints] Enabled Lazy Compilation by Hint"
This reverts commit 09fa63a935.

Reason for revert: Falkes on https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/29942

Original change's description:
> [wasm-hints] Enabled Lazy Compilation by Hint
> 
> Hints for lazy compilation are now taken into consideration. If the
> custom hints section suggests lazy compilatin we do so unless the module
> consists of a single function.
> 
> Bug: v8:9003
> Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
> Commit-Queue: Frederik Gossen <frgossen@google.com>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60557}

TBR=mstarzinger@chromium.org,clemensh@chromium.org,frgossen@google.com

Change-Id: I18dd424fe8cf05f220f7498bb1ebe4b9fce7d240
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9003
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547668
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60558}
2019-04-01 15:02:12 +00:00
Frederik Gossen
09fa63a935 [wasm-hints] Enabled Lazy Compilation by Hint
Hints for lazy compilation are now taken into consideration. If the
custom hints section suggests lazy compilatin we do so unless the module
consists of a single function.

Bug: v8:9003
Change-Id: Ibdc400453cee20d4d5c814733887b38fb675b220
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535827
Commit-Queue: Frederik Gossen <frgossen@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60557}
2019-04-01 14:32:21 +00:00
Sigurd Schneider
d4550f4ac1 Reland "[heap] Clean-up keys of oldspace weakmaps during scavenge"
This is a reland of 6604f1826d

Original change's description:
> [heap] Clean-up keys of oldspace weakmaps during scavenge
>
> This CL adds handling for cleaning up weakmap (EphemeronHashTable)
> keys during scavenge, even if the weakmap resides in oldspace.
>
> Change-Id: If8d711c050ddbcae4dd6e8da549e0c0d08ba47b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523787
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60432}

CQ_INCLUDE_TRYBOTS=luci.chrome.try:Mac Builder Perf

Change-Id: Ie640f2b0340637a5391fb17ba3c9e6422eaf306a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541476
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60554}
2019-04-01 13:59:56 +00:00
Deepti Gandluri
52d319e078 [wasm-simd] Fix I8x16 unsigned compares
Change-Id: Iad000c91323b9eef799b1e17f25bd3e9d345ab2d
Bug: v8:8635
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1543850
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60530}
2019-03-29 17:37:09 +00:00
Clemens Hammacher
33148af282 [heap][cleanup] Using 'using' instead of 'typedef'
Even though both are allowed in the style guide, it recommends to use
'using', as its syntax is more consistent with the rest of C++.
This CL turns all typedefs in heap code to 'using' declarations.

R=mstarzinger@chromium.org

Bug: v8:8834
Change-Id: I8a9f6e1eebdd0adca4373c866e95ebab0a1e992d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545892
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60523}
2019-03-29 12:15:30 +00:00
Clemens Hammacher
98b8715427 [wasm][cleanup] Using 'using' instead of 'typedef'
Even though both are allowed in the style guide, it recommends to use
'using', as its syntax is more consistent with the rest of C++.
This CL turns all typedefs in wasm code to 'using' declarations.

R=ahaas@chromium.org

Bug: v8:8834
Change-Id: Ibdce88a5cc31e0785cbc1b34088bd39aa3ec84b3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1545890
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60519}
2019-03-29 10:20:30 +00:00
Clemens Hammacher
45689a1ca1 [zone] Fix peak memory accounting
When switching from atomicops to std::atomic, I introduced a bug that
makes us miss the actual peak memory consumption, and only report the
second-highest memory usage in each zone.
This CL fixes that.

R=petermarshall@chromium.org

Bug: chromium:939724
Change-Id: I3db8eeb9719eb026cf6b4a9690c702cbc4c11bd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541227
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60505}
2019-03-28 13:39:11 +00:00
Dan Elphick
5376383cd7 [compiler] Make source position collection lazier
Previously when lazy source positions were enabled, source positions
were immediately collected whenever an exception was thrown for every
frame in the stack trace.

This change makes source position collection trigger only when the
source positions of a stack frame are actually accessed with the
exception of the top frame which is still eagerly collected for now.

Additionally when stack overflows occur during source position
collection, the bytecode is marked with exception in the
source_position_table field so it can be distinguished from the case
where source position collection has never been attempted (undefined)
or is not desired because the bytecode is for natives
(empty_byte_array).

Bug: v8:8510
Change-Id: If7ee68edbacc9e2adadf00fe5ec822a8dbe1c79a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520721
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60504}
2019-03-28 10:17:41 +00:00
Sigurd Schneider
613a1c2f3a [cctest] Add V8_EXPORT_PRIVATE for cctest (wasm part)
Bug: v8:9020
Change-Id: I3a939d65ec8468f034d4670d9b14a911e5ef5a61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541044
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60492}
2019-03-27 13:59:46 +00:00
Bill Budge
1c378d02c1 [wasm simd] Fix F32x4Min/Max bug with signaling NaNs.
- Fixes a bug where signaling NaNs are converted to
  Infinities rather than quiet NaNs.

Bug: v8:6020,v8:8639
Change-Id: I2601378f06f1987983f2b93e8970f401333073be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1536911
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60480}
2019-03-27 01:10:48 +00:00
Michael Achenbach
470aaf6699 Revert "[wasm] Implement table.init for interpreter"
This reverts commit 63608968b6.

Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Win32%20-%20debug/19535

Original change's description:
> [wasm] Implement table.init for interpreter
> 
> This also fixes CheckCallViaJS when a trap occurs. In that case, the
> trap callback is called instead of an exception being thrown, so if it
> isn't handled, a bogus result will be returned instead.
> 
> Bug: v8:8965
> Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ben Smith <binji@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60473}

TBR=binji@chromium.org,mstarzinger@chromium.org

Change-Id: Iee528ac2f16988b25579af3555e6f17974cb0b05
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8965
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539498
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60474}
2019-03-26 19:27:00 +00:00
Ben Smith
63608968b6 [wasm] Implement table.init for interpreter
This also fixes CheckCallViaJS when a trap occurs. In that case, the
trap callback is called instead of an exception being thrown, so if it
isn't handled, a bogus result will be returned instead.

Bug: v8:8965
Change-Id: I560e89f353756df23c062fb8c9484d9971c19253
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1539078
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60473}
2019-03-26 18:49:16 +00:00
Deepti Gandluri
fff8b5ca1d [wasm-simd] Fix Interpreter BitSelect and Boolean reductions
- Swap BitSelect operand order
 - Simplify, fix bugs for reductions

Bug: v8:8636, v8:8665
Change-Id: I9f43ac8007f9ecb317b1ffa4f99e9c249c58a2dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1534972
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60472}
2019-03-26 18:12:02 +00:00
Sigurd Schneider
6d0fe3e45a [cleanup] Free 400 targets from the draconic reign of..
..ordered-hash-table.h.

Bug: v8:8834
Change-Id: Ibb79006beb020d06bc516d9a2dac81015a403728
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538518
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60461}
2019-03-26 10:56:21 +00:00
Georg Neis
294671e832 [turbofan] Support GetSuperConstructor in serializer
Drive-by: also add support for trivial bytecodes such as LdaFalse.

Bug: v8:7790
Change-Id: I72626500096310899d37d57e3d0dd3bd54fddff4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532066
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60460}
2019-03-26 10:23:55 +00:00
Mythri
7629afdb9d [lite] Allocate feedback vectors lazily
Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.

Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
2019-03-25 16:02:38 +00:00
Benedikt Meurer
a2af7e1101 [tracing] Improve tracing signals for compilation/optimization.
This adds OBJECT/SNAPSHOT trace events for Script and SharedFunctionInfo
objects, logging their creation with appropriate information to make
sense of them.

Based on that we introduces five flow events to model the optimized
compilation via tracing in the "disabled-by-default-v8.compile" category:

  - "v8.optimizingCompile.start" logs the creation of the
    PipelineCompilationJob (for TurboFan JavaScript optimization)
    with the "function" argument referring to the trace event
    object created for the SharedFunctionInfo.
  - "v8.optimzingCompile.prepare" logs the preparation of the
    PipelineCompilationJob on the main thread, also carrying the
    "function" argument. This connects the flow event to the actual
    tracing duration event associated with the preparation phases.
  - "v8.optimizingCompile.execute" logs the (usually concurrent)
    optimization of the TurboFan graph (again with "function").
  - "v8.optimizingCompile.finalize" logs the main thread phase which
    finalizes the optimized code and eventually installs it (in case
    of success).
  - "v8.optimizingCompile.end" signals the end of the
    PipelineCompilationJob, which carries the "compilationInfo",
    that contains the interesting bits of the OptimizedCompilationInfo,
    specifically whether the compile was successfull and which functions
    were inlined for example.

This also adds two instant events "V8.AbortOptimization" and
"V8.RetryOptimization" in "disabled-by-default-v8.compile" category
that are emitted when TurboFan cannot optimize a certain function.
In case of "V8.RetryOptimization", TurboFan might be able to optimize
it later, whereas "V8.AbortOptimization" permanently disables the
optimization of a given function. The JSON representation of this is

```js
{
  "pid": 256639,
  "tid": 256639,
  "ts": 6935411377801,
  "tts": 159116,
  "ph": "I",
  "cat": "disabled-by-default-v8.compile",
  "name": "V8.AbortOptimization",
  "dur": 0,
  "tdur": 0,
  "args": {
    "reason": "Function is too big to be optimized",
    "function": {
      "id_ref": "0x600000001",
      "scope": "v8::internal::SharedFunctionInfo"
    }
  }
},
```

where the "function" refers to a previously emitted SNAPSHOT for the
function in question. In the trace viewer it will show up as instant
event under "v8.optimizingCompile.prepare" in case of the relevant
example where optimization is disabled due to reaching the bytecode
limit (as in the JSON above), i.e. it'll look something like this

  https://i.paste.pics/aafc2de9df10ea8f5acc1a761d80f07b.png

for the example highlighted in the recent blog post

  https://ponyfoo.com/articles/javascript-performance-pitfalls-v8

that describes the optimization limit. The "v8.optimizingCompile.end"
duration event will also carry this information as part of the
"compilationInfo" object, but specifically for CI tools, etc. it might
be a whole lot easier to just look for the "V8.AbortOptimization"
instant event.

Bug: v8:8598, v8:9039
Tbr: ulan@chromium.org
Doc: bit.ly/v8-tracing-signals
Change-Id: Ic87ac336004690c65b6b15ad73bc6fbd4b5f12c4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1511483
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60448}
2019-03-25 14:49:08 +00:00
Sigurd Schneider
24038b9357 Revert "[heap] Clean-up keys of oldspace weakmaps during scavenge"
This reverts commit 6604f1826d.

Bug: chromium:945341

Original change's description:
> [heap] Clean-up keys of oldspace weakmaps during scavenge
> 
> This CL adds handling for cleaning up weakmap (EphemeronHashTable)
> keys during scavenge, even if the weakmap resides in oldspace.
> 
> Change-Id: If8d711c050ddbcae4dd6e8da549e0c0d08ba47b2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523787
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60432}

TBR=ulan@chromium.org,jarin@chromium.org,sigurds@chromium.org,leszeks@chromium.org

Change-Id: I9dd9b11990a262a457fd1bedc2b45b4a786a81f7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538133
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60447}
2019-03-25 14:31:03 +00:00
Peter Marshall
bad7b827f0 [cleanup] Clean up trace event tests by removing macros
The macros take implicit local arguments and make the tests harder to
read. Remove the macros and add a helper to get size directly given
this is the only use of the helper that returns the whole list.

Remove the typedef of vector of trace events, because it is only used
in two places now and is also called 'list' not vector.

Use unique pointers for the ownership of MockTraceObject.

Change-Id: Iec495c436cf7326224137321a84035c817622eaa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1538131
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60443}
2019-03-25 13:46:58 +00:00
Sigurd Schneider
6604f1826d [heap] Clean-up keys of oldspace weakmaps during scavenge
This CL adds handling for cleaning up weakmap (EphemeronHashTable)
keys during scavenge, even if the weakmap resides in oldspace.

Change-Id: If8d711c050ddbcae4dd6e8da549e0c0d08ba47b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1523787
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60432}
2019-03-25 10:52:57 +00:00
Clemens Hammacher
83f76ba3b5 [wasm] Rename inl headers that can be plain headers
Both js-to-wasm-wrapper-cache-inl.h and wasm-import-wrapper-cache-inl.h
do not include any inl headers, thus they can be plain headers. If they
ever need to include inl headers again, we should split out the
respective functions into a separete inl header to follow the usual
pattern to have *both* a plain header *and* an inl header.

R=mstarzinger@chromium.org

Bug: v8:8834
Change-Id: I1b1b917a8e2c47f1354522479f8c57475bee6244
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1535826
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60431}
2019-03-25 10:48:34 +00:00
Bill Budge
aa706218d6 [wasm simd] Make F32x4Min/Max IEEE 754 compliant
- Changes min and max sequences to propagate NaNs and signed
  zeroes.

- Note that NaN propagation must preserve canonical NaNs. This is
  achieved by always returning canonical NaNs. This is also
  consistent with the WebAssembly scalar math spec.

Bug: v8:8639
Change-Id: I04fdefabc54ea60f4d02e2081c32444a02dd6a83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1524634
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60414}
2019-03-22 18:26:23 +00:00
Ben Smith
8a7f562e14 [wasm] Implement bulk memory table.copy in interpreter
Most of the mjsunit/wasm/table-copy.js tests have been ported to
cctests, so they can be tested with all execution tiers.

Bug: v8:8965
Change-Id: I448719be30a4b2bddb9e2cffb4c74d3134db2f50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529548
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60396}
2019-03-21 16:26:20 +00:00
Santiago Aboy Solanes
c0556c162b [Turbofan][ptr-compr] Handle "compress changes" in the instruction selector
Said instructions look like ChangeTaggedXXXToCompressedXXX and
ChangeCompressedXXXToTaggedXXX for XXX in ("", "Pointer", "Signed").

This change only affects 64 bit architectures (both for x64 and arm64).

Also added tests for the machine operators.

Cq-Include-Trybots: luci.v8.try:v8_linux64_pointer_compression_rel_ng,v8_linux64_arm64_pointer_compression_rel_ng
Bug: v8:8977
Change-Id: I239d9de7f214424852e75b5d56996e8dfdacd400
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1526009
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60393}
2019-03-21 14:46:11 +00:00
Michael Lippautz
c4eae87a1a heap: Fix incremental-concurrent processing of large FixedArray
FixedArray object in LO space are processed incrementally in ranges of slots
size kProgressBarScanningChunk to reduce latency when returning to the
processing loop is critical. A progress bar stores how much slots have been
processed already.

In the case of regular concurrent marking there was a guarantee that the
object was only processed by one thread (main *or* concurrent marking
thread) at the same time.

However, some optimizations that avoid write barriers for each
individual write operation emit a batched write barrier that requires
re-visiting the FixedArray for the marking barrier. In such cases, the
progress bar would be reset using relaxed stores which is problematic as
the concurrent marking thread could race on setting its own progress on the
progress bar. As a result, the array would only be re-scanned partially.

The fix involves using CAS to set the progress bar and bail out in the
case an inconsistent state was observed.

In the following:
MT... main thread
CM... concurrent marking thread

The interesting cases are:
1. MT *or* CM processes the array without interfering: Progress bar is
   updated monotonically without failing.
3. MT interferes with itself: The progress bar is just reset and the main
   thread will restart scanning from index 0. The object is added twice to
   the marking worklist and processed each time one of the entries is
   retrieved from the worklist.
4. MT interferes with CM:
   4.a.: CM processes a range of slots and re-adds the left overs by
   setting the progress bar and re-adding the array to the worklist.  In
   this case CM *and* MT process the array from index 0. The first time
   the CAS for setting the progress bar fails on either of the threads,
   the looser will bail out and leave processing for the winner.
   4.b.: CM is interrupted while processing a range of the array and
   fails in setting the progress bar for the left overs. In this case
   the CM bails out right away and the main thread starts processing
   from index 0.

In addition, there is a transition from index 0 to the index of the
first actual slot. This transition makes it possible to observe a reset
while processing the first actual chunk of slots.

Bug: chromium:942699
Change-Id: I0b06f47ee075030dadfc959528cd77b6b69bbec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532325
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60385}
2019-03-21 09:21:58 +00:00
Andreas Haas
2d9ec0a420 Reland: [wasm][anyref] Add support of call-indirect for multiple tables
The reason for the revert was that Liftoff did not bail out on indirect
calls to tables other than table 0. Whenever the Liftoff code got
executed, the test would fail.

Original message:
With this CL it is possible to use any anyfunc table in call-indirect,
not just the first table.

The current implementation is based on runtime calls. This is just an
initial implementation which should be replaced by a
dispatch-table-based eventually. However, this implementation allows
us to move forward with the anyref proposal implementation.

R=mstarzinger@chromium.org

Bug: v8:7581
Change-Id: Iedd56ee7acb281441bca32ffd3dc7157203ee1ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532072
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60382}
2019-03-21 08:42:48 +00:00
Ben Smith
1a88414c41 [wasm] Call through dispatch table in interpreter
When running wasm tests, the interpreter previously used a static
collection of function indexes stored in WasmTable to perform
call_indirect calls internal to that module. This has the wrong behavior
if the table is changed (via WasmTableObject::Set, `table.copy`, or
`table.init`).

This CL changes the cctests to always generate an intepreter entry for
all functions, and stores those entries in the dispatch table. This
allows us to use the same execution path as for non-testing code.

The interpreter entry compiler needed to be changed to support
multi-value returns too, since a 64-bit integer return value may be
lowered to two 32-bit integer returns.

Bug: v8:9016
Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60380}
2019-03-21 07:35:27 +00:00
Leszek Swirski
9f6ddb48a0 Revert "V8 x64 backend doesn't emit ABI compliant stack frames"
This reverts commit 3cda21de77.

Reason for revert: Breaks the roll on Windows (see https://cr-buildbucket.appspot.com/build/8918477701097622400)

Original change's description:
> V8 x64 backend doesn't emit ABI compliant stack frames
> 
> On 64 bit Windows, the OS stack walking does not work because the V8 x64
> backend doesn't emit unwinding info and also because it doesn't emit ABI
> compliant stack frames. See
> https://docs.google.com/document/d/1-wf50jFlii0c_Pr52lm2ZU-49m220nhYMrHDi3vXnh0/edit
> for more details.
> 
> This problem can be fixed by observing that V8 frames usually all have the same
> prolog and epilog:
> 
> push rbp,
> mov rbp, rsp
> ...
> pop rbp
> ret N
> 
> and that it is possible to define XDATA (UNWIND_CODEs) that specify how Windows
> should walk through V8 frames. Furthermore, since V8 Code objects are all
> allocated in the same code-range for an Isolate, it is possible to register a
> single PDATA/XDATA entry to cover stack walking for all the code generated
> inside that code-range.
> 
> This PR contains changes required to enable stack walking on Win64:
> 
> EmbeddedFileWriter now adds assembler directives to the builtins
> snapshot source file (embedded.cc) to emit additional entries in the .pdata and
> in the .xdata section of the V8 executable. This takes care of stack walking
> for embedded builtins. (The case of non-embedded builtins is not supported).
> The x64 Assembler has been modified to collect the information required to emit
> this unwind info for builtins.
> 
> Stack walking for jitted code is handled is Isolate.cpp, by registering
> dynamically PDATA/XDATA for the whole code-range address space every time a new
> Isolate is initialized, and by unregistering them when the Isolate is
> destroyed.
> 
> Stack walking for WASM jitted code is handled is the same way in
> wasm::NativeModule (wasm/wasm-code-manager.cpp).
> 
> It is important to note that Crashpad and Breakpad are already registering
> PDATA/XDATA to manage and report unhandled exceptions (but not for embedded
> builtins). Since it is not possible to register multiple PDATA entries for the
> same address range, a new function is added to the V8 API:
> SetUnhandledExceptionCallback() can be used by an embedder to register its own
> unhandled exception handler for exceptions that arise in v8-generated code.
> V8 embedders should be modified accordingly (code for this is in a separate PR
> in the Chromium repository:
> https://chromium-review.googlesource.com/c/chromium/src/+/1474703).
> 
> All these changes are experimental, behind:
> 
> the 'v8_win64_unwinding_info' build flag, and
> the '--win64-unwinding-info' runtime flag.
> 
> Bug: v8:3598
> Change-Id: Iea455ab6d0e2bf1c556aa1cf870841d44ab6e4b1
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1469329
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Paolo Severini <paolosev@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#60330}

TBR=bbudge@chromium.org,ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,jgruber@chromium.org,paolosev@microsoft.com

Change-Id: If8470da94c58df8c800cbe8887f9f86236e43353
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:3598
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532321
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60372}
2019-03-20 14:36:04 +00:00
Clemens Hammacher
25d8a157b1 [wasm] Split adding code from publishing it
This prepares a refactoring to add and publish compilation results in
batches. For this, we need to separate the two phases, so that we can
lock the module, allocate all the code space, release the lock, copy
the code, lock the module, publish the code, and release the lock
again.
In particular, this CL does the following:
1) It removes the {AddOwnedCode} method. The functionality of creating
   the {WasmCode} and memcpy'ing the instruction into that is done in
   the other {Add*Code} methods. Adding to {owned_code_} is done in
   {PublishCode}.
2) {PublishInterpreterEntry} is now functionally equivalent to
   {PublishCode}, so it's removed.
3) After {AddCode}, the caller has to call {PublishCode}. In a
   follow-up CL, this will be called in batches (first {AddCode} them
   all, then {PublishCode} them all).
4) {AddCompiledCode} now assumes that the {WasmCompilationResult}
   succeeded. Otherwise, the caller should directly call {SetError} on
   the {CompilationState}.
5) {PublishCode} is now the chokepoint for installing code to the code
   table, the owned code vector, the jump table, and setting interpreter
   redirections. It replaces previous direct calls to {InstallCode} or
   explicitly adding to {owned_code_}.
6) Increasing the {generated_code_size_} counter is now done in
   {AllocateForCode}, which is the chokepoint for allocating space for
   generated code. This way, we will only increase this counter once
   once we allocate in batches.

R=titzer@chromium.org

Bug: v8:8916
Change-Id: I71e02e3a838f21797915cee3ebd373804fb12237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530817
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60369}
2019-03-20 13:39:11 +00:00
Andreas Haas
c808b934d3 Revert "[wasm][anyref] Add support of call-indirect for multiple tables"
This reverts commit 9d167f57e0.

Reason for revert: There is a crash on https://ci.chromium.org/p/v8/builders/ci/V8%20Win32/20026

Original change's description:
> [wasm][anyref] Add support of call-indirect for multiple tables
> 
> With this CL it is possible to use any anyfunc table in call-indirect,
> not just the first table.
> 
> The current implementation is based on runtime calls. This is just an
> initial implementation which should be replaced by a
> dispatch-table-based eventually. However, this implementation allows
> us to move forward with the anyref proposal implementation.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: v8:7581
> Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60360}

TBR=mstarzinger@chromium.org,ahaas@chromium.org

Change-Id: Iba4b84078aa070498be7e79212970b94595f5757
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7581
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532069
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60362}
2019-03-20 11:52:37 +00:00
Andreas Haas
9d167f57e0 [wasm][anyref] Add support of call-indirect for multiple tables
With this CL it is possible to use any anyfunc table in call-indirect,
not just the first table.

The current implementation is based on runtime calls. This is just an
initial implementation which should be replaced by a
dispatch-table-based eventually. However, this implementation allows
us to move forward with the anyref proposal implementation.

R=mstarzinger@chromium.org

Bug: v8:7581
Change-Id: I57d09b18add7f525555bf7c949aef17a64b0e7c5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530801
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60360}
2019-03-20 11:33:16 +00:00
Vadim Gorbachev (bmsdave)
631213f6f6 Reland "Preparing v8 to use with python3 /test"
This is a reland of f8962ae1a2

Original change's description:
> Preparing v8 to use with python3 /test
>
> There are now less that 400 days until the end of life
> of Python 2(aka _legacy_ Python) https://pythonclock.org/ .
> The code compatibility check for python2 and python3
> used the following tools: futurize, flake8
> You can see the reports here: https://travis-ci.com/bmsdave/v8/builds
>
> This CL was uploaded by git cl split.
>
> Bug: v8:8594
> Change-Id: Idbf467daf629a4e808345a6a88036c2a3f259138
> Reviewed-on: https://chromium-review.googlesource.com/c/1470121
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59679}

Bug: v8:8594
Change-Id: I8c1a8d6593a4a927d56d37dada2c704062e842cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1484300
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Sergiy Belozorov <sergiyb@chromium.org>
Commit-Queue: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60354}
2019-03-20 09:56:06 +00:00
Michael Lippautz
73c62c845e profiler: Provide raw heap snapshots
Omit user roots when raw heap snapshots are used, i.e., when
the gn flag v8_enable_raw_heap_snapshots is enabled. For regular
Chrome production builds this is not the case.

Blink CL: https://crrev.com/c/1529096

Bug: chromium:936797
Change-Id: I5ae0ec1ecfab9a76352d8ce927d1c40e707262cc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1528994
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60351}
2019-03-20 09:27:32 +00:00
Ben Smith
ea9e5a7664 [wasm] Rename CheckCallViaJS with argument array
WasmRunner provides CheckCallViaJS, which calls a wasm function through
JS and checks its result.

There are currently two overloads, one that takes a variable number of
arguments, and another more general 4-argument version that takes an
array of arguments. This means if you run code like:

    r.CheckCallViaJS(0, 0, 0, 0);

The overload resolution kicks in, and chooses the general version, which
will always segfault.

This CL renames the general version to `CheckCallApplyViaJS` so the
above example will call the variable-argument version instead.

Change-Id: I14a742c467692e09e84f03504cec2306a794fc24
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529990
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60345}
2019-03-20 04:17:31 +00:00