An unordered_map typically provides better performance. Instead of a
compare function, we now need a hash function and equality defined on
{Signature<T>}.

R=mstarzinger@chromium.org

Bug: chromium:862123
Change-Id: Iba71030f91949d7453740c884de1d8a4f921c618
Reviewed-on: https://chromium-review.googlesource.com/1131182
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54404}

Restores some sensemaking properties, such as making src/machine-type.h (lower
level header) independent of src/zone/zone.h (higher level header).

BUG=v8:7490

Change-Id: Ibc6e5c7a75e4aaf917d086cf70267abc7ee9a9b0
Reviewed-on: https://chromium-review.googlesource.com/1039586Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52941}

Both lazy initialization and static initialization (via static
initializer) are bad. Fortunately, the arrays we are constructing are
constant anyway, so we can just compute them at compile time. This is
enforced by making them constexpr.
This also saves all code needed for the initialization, and makes
accesses to the tables faster, as they don't need any atomic operations
(via LazyInstance).

R=ahaas@chromium.org

Change-Id: I7d3ba9b0f2602f596a6c71c8c567e0d1bc306268
Reviewed-on: https://chromium-review.googlesource.com/517083
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45589}

This introduces iterators for the parameters and return types of a
signature. This required extending the constructor of iterator_range
for perfect forwarding.

I also moved the HasJSCompatibleSignature to a header file in order to
reuse it from the interpreter.

R=ahaas@chromium.org, titzer@chromium.org

Change-Id: Ie77f87ef87fdfd3138b2106640ac7c481cf247e6
Reviewed-on: https://chromium-review.googlesource.com/455777
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43854}

The generated code for JSToWasm wrappers only depends on the signature
of the exported function. Hence, we can reuse the generated code and
just patch the reference to the called wasm code.

For the unity-wasm benchmark, we reach a hit rate of 98.07% for this
cache, and only 395 instead of 20471 wrappers are compiled. This brings
down instantiation time from 2.9s to 1.6s on a MBP.

R=titzer@chromium.org

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

This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.

This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.

Additionally, this CL implements the proper base + offset initialization
behavior for tables.

R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316

Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}

This is some initial cleanup to keep /src clean. The
AccountingAllocator is actually exclusively used by zones and this
common subfolder makes that more clear.

BUG=v8:5409

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

This reverts commit 1eb1dfab.

The original compilation separation change avoided associating a heap
for the wasm instance if memory was not provided, nor needed. The
grow memory CL assumed the old behavior, where a memory buffer was
always present, but may have had a zero size.

The 2CLS  landed shortly after one another. We decided to treat the
grow memory as the race condition winner, so this CL here re-lands
compilation separation, plus adjusts grow memory to deal with
the undefined mem buffer.

BUG=

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

This reverts commit 0c7ee927.

BUG=

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

Support for serializing/deserializing the compiled wasm module.

We want to reuse the javascript snapshotting mechanics, at least in the
short term, when we still use the JS heap for the compiled wasm code.
Given that a module may be compiled in one v8 instance and then
instantiated later, in a different instance, whatever information we need
at instantiation time must also be serializable.

We currently hold on to the un-decoded wasm bytes, for enabling
debugging scenarios. This imposes a ~20% penalty on the memory
requirements of the wasm compiled code. We do not need this data
otherwise, for runtime, and it is sensible to consider eventually loading it
on demand. Therefore, I intentionally avoided relying on it and re-
decoding the wasm module data, and instead saved the information
necessary to support instantiation.

Given how whatever we need to persist must be serializable, the CL
uses a structure made out of serializable objects (fixed arrays mostly)
for storing this information. I preferred going this route rather than
adding more wasm-specific support to the serializer, given that we want
to eventually move off the JS heap, and therefore the serializer.

Additionally, it turns out this extra information is relatively not complex:
minimal structure, little nesting depth, mostly simple data like numbers
or byte blobs, or opaque data like compiled functions.

This CL also moves export compilation ahead of instantiation time.

This change added a helper getter to FixedArray, to make typed retrieval
of elements easier.

BUG=

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

R=bmeurer@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1118823003

Cr-Commit-Position: refs/heads/master@{#28191}