- 27 May, 2019 1 commit
-
-
Clemens Hammacher authored
This replaces all typedefs that define types and not functions by the equivalent "using" declaration. This was done mostly automatically using this command: ag -l '\btypedef\b' src test | xargs -L1 \ perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg' Patchset 2 then adds some manual changes for typedefs for pointer types, where the regular expression did not match. R=mstarzinger@chromium.org TBR=yangguo@chromium.org, jarin@chromium.org Bug: v8:9183 Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61849}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
Bug: v8:9247 TBR=bmeurer@chromium.org,neis@chromium.org NOPRESUBMIT=true Change-Id: Ia1e49d1aac09c4ff9e05d58fab9d08dd71198878 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1621931Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61682}
-
- 12 Dec, 2018 1 commit
-
-
Andreas Haas authored
To allow any-ref parameters, we have to make sure that any-ref stack parameters get seen by the GC. This CL is a first step into that direction. The goal of this CL is to group any-ref parameters at the stack side of the parameters. This means that in the stack frame iterator we do not need information about where anyref parameters are in the stack frame. We only need information about how many anyref parameters there are at the bottom of the stack frame. R=mstarzinger@chromium.org Also-By: mstarzinger@chromium.org Bug: v8:7581 Change-Id: I3ff7cc38fabed5f8e51b5b990190e35f3ea29803 Reviewed-on: https://chromium-review.googlesource.com/c/1371827 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58184}
-
- 04 Dec, 2018 1 commit
-
-
Sven Sauleau authored
Replaces some DCHECK with their verbose equivalent because it's more convenient while debugging. Change-Id: I83c199c389341a68dfccd949e7353ef68ff3b9c2 Reviewed-on: https://chromium-review.googlesource.com/c/1352289Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#58013}
-
- 12 Jul, 2018 1 commit
-
-
Clemens Hammacher authored
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}
-
- 03 May, 2018 1 commit
-
-
Marja Hölttä authored
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}
-
- 30 May, 2017 1 commit
-
-
Clemens Hammacher authored
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}
-
- 16 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
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}
-
- 20 Feb, 2017 1 commit
-
-
clemensh authored
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}
-
- 19 Oct, 2016 1 commit
-
-
titzer authored
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}
-
- 20 Sep, 2016 1 commit
-
-
heimbuef authored
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}
-
- 28 Jun, 2016 3 commits
-
-
mtrofin authored
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}
-
mtrofin authored
This reverts commit 0c7ee927. BUG= Review-Url: https://codereview.chromium.org/2103983003 Cr-Commit-Position: refs/heads/master@{#37351}
-
mtrofin authored
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}
-
- 04 May, 2015 1 commit
-
-
titzer authored
R=bmeurer@chromium.org BUG= Review URL: https://codereview.chromium.org/1118823003 Cr-Commit-Position: refs/heads/master@{#28191}
-