- 02 Jul, 2018 1 commit
-
-
Michael Starzinger authored
This makes sure the reverse tag translation of direct call targets to respective call tags is properly performed. Otherwise all direct call end up being deserialized to call the function with index '0'. Ooops! R=clemensh@chromium.org TEST=mjsunit/wasm/compiled-module-serialization BUG=chromium:857049 Change-Id: I37c1ee72b000daec87efdeed08d60a067b1a1b0c Reviewed-on: https://chromium-review.googlesource.com/1120256Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54124}
-
- 29 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
No need to go via the {ModuleEnv} in the {CompilationState}. R=mstarzinger@chromium.org Change-Id: I11ff647824ad107131ce329453b365d6ecaec7fb Reviewed-on: https://chromium-review.googlesource.com/1118561Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54102}
-
- 28 Jun, 2018 3 commits
-
-
Clemens Hammacher authored
Another pair of {std::unique_ptr} and {size_t} that can be stored as one {OwnedVector}, which allows to pass it as one thing. R=mstarzinger@chromium.org Bug: v8:7754 Change-Id: Ideac0dbd390ba8147b6620daa86f0d3da6c3b609 Reviewed-on: https://chromium-review.googlesource.com/1118236 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54091}
-
Clemens Hammacher authored
Instead of storing both the {NativeModule} and the {WasmModule} in a {Managed} object, just store the {WasmModule} in the {NativeModule} directly. This fixes crashes that happen if the {Managed<WasmModule>} dies before the {Managed<NativeModule>}. R=mstarzinger@chromium.org Bug: chromium:854794, v8:7879, v8:7889 Change-Id: I6b11729943fe7a03d225138782655ee5dafd26a6 Reviewed-on: https://chromium-review.googlesource.com/1118171 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54090}
-
Clemens Hammacher authored
This CL removes the friendship between {NativeModule} and {NativeModuleSerializer}/{NativeModuleDeserializer}. Instead, it adds a new public method ({AddDeserializedCode}) which is being called from the deserializer. Drive-by: Unify the argument order to {AddCode}, {AddOwnedCode} and {WasmCode}. R=mstarzinger@chromium.org Bug: chromium:856938 Change-Id: I88943c90c45650e21ae6bc17395a17f86319c046 Reviewed-on: https://chromium-review.googlesource.com/1117075Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54084}
-
- 27 Jun, 2018 4 commits
-
-
Clemens Hammacher authored
The name itself does not make sense any more since the {NativeModule} is shared across instances. It is also only used for debugging, so remove it, and replace it by the address of the {NativeModule} itself in debug output. R=mstarzinger@chromium.org Bug: v8:7754 Change-Id: I02f9252981b776934811a904287be31c7076e90b Reviewed-on: https://chromium-review.googlesource.com/1114965 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54064}
-
Clemens Hammacher authored
Since the Liftoff prologue is gone (https://crrev.com/c/1110222), this field is dead. R=mstarzinger@chromium.org Bug: v8:6600 Change-Id: I9d3e94a63087e7111939523c11fba4f009cecd54 Reviewed-on: https://chromium-review.googlesource.com/1116963Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54059}
-
Clemens Hammacher authored
Replace two more pairs of {std::unique_ptr} and {size_t} by {OwnedVector}. R=mstarzinger@chromium.org Change-Id: Ifdf03abf9759fbbb4adde76a494073625723a03d Reviewed-on: https://chromium-review.googlesource.com/1116785 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54057}
-
Clemens Hammacher authored
We currently store the protected instructions per code object in a {std::unique_ptr<std::vector<ProtectedInstructionData>>}. This wastes memory, because it requires two heap allocations, plus the vector might over-allocate (and it currently does, because it is filled dynamically during compilation). This CL changes that to store the protected instructions in an {OwnedVector}. This requires one copy after generating the list of {ProtectedInstructionData} in an {std::vector} during compilation, but saves memory afterwards. R=mstarzinger@chromium.org Bug: chromium:856938 Change-Id: Ie290a17dc32f27fbbfe0c000a52297181c954550 Reviewed-on: https://chromium-review.googlesource.com/1116701Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54052}
-
- 26 Jun, 2018 1 commit
-
-
Michael Starzinger authored
R=titzer@chromium.org BUG=v8:7424 Change-Id: I1e5f41fba6cc575001cac1fd0a862736784a2131 Reviewed-on: https://chromium-review.googlesource.com/1113456 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#54021}
-
- 25 Jun, 2018 1 commit
-
-
Michael Starzinger authored
R=titzer@chromium.org Change-Id: I760a2568194edce486383d2bf32d598bdb9d44b1 Reviewed-on: https://chromium-review.googlesource.com/1109938Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#54001}
-
- 22 Jun, 2018 3 commits
-
-
Clemens Hammacher authored
The wire bytes are currently stored as {SeqOneByteString} on the JS heap. In order to make the {NativeModule} isolate independent, and to ensure fast access to the wire bytes, they should move to the native heap. R=titzer@chromium.org Bug: chromium:854794, v8:7868, v8:7424 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I36811ec87f780c5b1f6863cd6de89a165aa0b7d5 Reviewed-on: https://chromium-review.googlesource.com/1108208 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53977}
-
Michael Starzinger authored
This changes the WebAssembly pipeline to no longer expect source position tables for {WasmCode} to be allocated on the GC'ed heap. R=clemensh@chromium.org BUG=v8:7721 Change-Id: Ib2c6e3d0840e47b83809f60519c0d1b94af186af Reviewed-on: https://chromium-review.googlesource.com/1109686 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53961}
-
Clemens Hammacher authored
This prologue is not needed any more now that we have the jump table. If optimized code exists, we will not even enter the Liftoff code any more, but instead jump to the optimized code right away. This also allows to remove the {WASM_CODE_TABLE_ENTRY} relocation info kind. R=mstarzinger@chromium.org Bug: v8:7758 Change-Id: I0449693d7434088fb264104fe59365d7ca2b74c6 Reviewed-on: https://chromium-review.googlesource.com/1110222Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53954}
-
- 21 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
This CL adds a builtin which receives an int32 argument and returns the int32 result. Internally, it checks whether the argument is in the valid smi range, then calls the runtime function with the smi argument and converts the return value back from smi to int32. This saves a lot of code in the wasm TF builder and in Liftoff. R=mstarzinger@chromium.org Bug: v8:6600 Change-Id: Icddcb020eae74c767a75090feb4939275432c007 Reviewed-on: https://chromium-review.googlesource.com/1107711 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53946}
-
- 20 Jun, 2018 2 commits
-
-
Michael Starzinger authored
R=clemensh@chromium.org Change-Id: Ic16e1da4ca50070ceff7f9a441250db2d20a868f Reviewed-on: https://chromium-review.googlesource.com/1104471 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53871}
-
Clemens Hammacher authored
The {ModuleEnv} already contains a pointer to the {WasmModule}, no need to pass it explicitly. R=titzer@chromium.org Change-Id: Icf0e8ea8b25c33dd5bcaeab2a4a746376e73813d Reviewed-on: https://chromium-review.googlesource.com/1105828 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53858}
-
- 19 Jun, 2018 2 commits
-
-
Michael Starzinger authored
This makes sure we use WebAssembly runtime stubs when performing value coercions in wrapper code that is compiled into {WasmCode}. It hence removes the last {RelocInfo::CODE_TARGET} references in {WasmCode}. R=clemensh@chromium.org BUG=v8:7424 Change-Id: Ic96e541abe98f90796a6506b09ff99557743b6f7 Reviewed-on: https://chromium-review.googlesource.com/1104462 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53846}
-
Clemens Hammacher authored
This is a reland of 733b7c82. The arm64 bug was fixed in https://crrev.com/c/1105051. Original change's description: > [wasm] Introduce jump table > > This introduces the concept of a jump table for WebAssembly, which is > used for every direct and indirect call to any WebAssembly function. > For lazy compilation, it will initially contain code to call the > WasmCompileLazy builtin, where it passes the function index to be > called. > For non-lazy-compilation, it will contain a jump to the actual code. > The jump table allows to easily redirect functions for lazy > compilation, tier-up, debugging and (in the future) code aging. After > this CL, we will not need to patch existing code any more for any of > these operations. > > R=mstarzinger@chromium.org, titzer@chromium.org > > Bug: v8:7758 > Change-Id: I45f9983c2b06ae81bf5ce9847f4542fb48844a4f > Reviewed-on: https://chromium-review.googlesource.com/1097075 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53805} TBR=titzer@chromium.org,mstarzinger@chromium.org Bug: v8:7758 Change-Id: I68555230c6db97e70f0b8fef784188f55ee04794 Reviewed-on: https://chromium-review.googlesource.com/1105158 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53829}
-
- 18 Jun, 2018 3 commits
-
-
Clemens Hammacher authored
This reverts commit 733b7c82. Reason for revert: breaks arm64 gc-stress: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/11659 Original change's description: > [wasm] Introduce jump table > > This introduces the concept of a jump table for WebAssembly, which is > used for every direct and indirect call to any WebAssembly function. > For lazy compilation, it will initially contain code to call the > WasmCompileLazy builtin, where it passes the function index to be > called. > For non-lazy-compilation, it will contain a jump to the actual code. > The jump table allows to easily redirect functions for lazy > compilation, tier-up, debugging and (in the future) code aging. After > this CL, we will not need to patch existing code any more for any of > these operations. > > R=mstarzinger@chromium.org, titzer@chromium.org > > Bug: v8:7758 > Change-Id: I45f9983c2b06ae81bf5ce9847f4542fb48844a4f > Reviewed-on: https://chromium-review.googlesource.com/1097075 > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Ben Titzer <titzer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#53805} TBR=mstarzinger@chromium.org,titzer@chromium.org,clemensh@chromium.org,sreten.kovacevic@mips.com Change-Id: Iea358db2cf13656a65cf69a6d82cbbc10d3e7e1c No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7758 Reviewed-on: https://chromium-review.googlesource.com/1105157Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53807}
-
Clemens Hammacher authored
This introduces the concept of a jump table for WebAssembly, which is used for every direct and indirect call to any WebAssembly function. For lazy compilation, it will initially contain code to call the WasmCompileLazy builtin, where it passes the function index to be called. For non-lazy-compilation, it will contain a jump to the actual code. The jump table allows to easily redirect functions for lazy compilation, tier-up, debugging and (in the future) code aging. After this CL, we will not need to patch existing code any more for any of these operations. R=mstarzinger@chromium.org, titzer@chromium.org Bug: v8:7758 Change-Id: I45f9983c2b06ae81bf5ce9847f4542fb48844a4f Reviewed-on: https://chromium-review.googlesource.com/1097075 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53805}
-
Clemens Hammacher authored
We currently have a system where the protected instructions are unregistered when the last instance dies, and registered again on the next instantiation. This is triggered by {WasmCompiledModule::Reset}. Since the reference to the {NativeModule} will move to the {WasmModuleObject}, and this object stays alive even if the last instance dies, this will become hard to maintain. It will also make it harder to share wasm code across isolates. This CL refactors this to register trap handler data once when the code is added to the {NativeModule}, and releases it if the code dies. R=mstarzinger@chromium.org CC=eholk@chromium.org Bug: v8:5277 Change-Id: I3f1b336095230b255f3849c271b37b62f2b96cd6 Reviewed-on: https://chromium-review.googlesource.com/1103567 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53791}
-
- 15 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
{LogWasmCodes} is independent of the runtime object, so it should be defined on the {NativeModule}. R=herhut@chromium.org Change-Id: I1202b18264ef0367004ba80e0030b057c633b62f Reviewed-on: https://chromium-review.googlesource.com/1102424Reviewed-by:
Stephan Herhut <herhut@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53764}
-
- 14 Jun, 2018 1 commit
-
-
Michael Starzinger authored
This allows WebAssembly runtime stubs implemented as {WasmCode} to be called with regular stub linkage. So far we have only been able to call such stubs with WebAssembly linkage. Also switch two more on-heap builtins over to WebAssembly runtime stubs. R=clemensh@chromium.org BUG=v8:7424 Change-Id: Ifa553b5908ee27a1be780c325a114449d7fe7001 Reviewed-on: https://chromium-review.googlesource.com/1100882Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53734}
-
- 13 Jun, 2018 3 commits
-
-
Michael Starzinger authored
This uses a WebAssembly runtime stub for the out-of-line {DoubleToI} computation instead of a builtin specific to a certain Isolate. It is another step towards making {WasmCode} independent of the Isolate. R=clemensh@chromium.org BUG=v8:7424 Change-Id: Ifdaa8e2511b67468d75e0e4aaf70010ced04a11a Reviewed-on: https://chromium-review.googlesource.com/1098672 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#53702}
-
Ben L. Titzer authored
Previously, we sent a critical low memory pressure notification when attempting to commit WASM code when the code manager was near the limit for total amount of code allocated. https://chromium-review.googlesource.com/c/v8/v8/+/1073412 "fixed" that, but it causes OOMs on Windows. Since we no longer have the isolate on the code manager, and thus cannot send this notification on commit, send the notification upon the next module creation. This is still not optimal, but should fix OOM issues for lots of small modules on Windows. BUG=v8:7845 R=mstarzinger@chromium.org CC=clemensh@chromium.org Change-Id: I6e20d0c1ee9bc6926a83e0c2fbdc9e9e453588ec Reviewed-on: https://chromium-review.googlesource.com/1098921 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53700}
-
Clemens Hammacher authored
The {WasmSharedModuleData} struct was introduced to hold data common to all wasm instances belonging to the same module. The idea was to keep "internal state" separate from the JS-facing {WasmModuleObject}. Since this objective has no real value, and we already store some internal data on the {WasmModuleObject}, this CL merges these two objects. R=titzer@chromium.org, mstarzinger@chromium.org Bug: v8:7754 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I04f6d07bf5d812bc4717af26f0f64231345861f9 Reviewed-on: https://chromium-review.googlesource.com/1097491 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53698}
-
- 12 Jun, 2018 3 commits
-
-
Ben L. Titzer authored
The isolate is mainly used for accounting purposes. As such, it doesn't need a field in the WasmCodeManager, and cannot have one if it is to be made isolate independent. Instead, pass the isolate explicitly in the appropriate cases. R=mstarzinger@chromium.org BUG=v8:7424 Change-Id: I539c2b33692e57605a280530bd704ef25269ad0f Reviewed-on: https://chromium-review.googlesource.com/1073412 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53676}
-
Ben L. Titzer authored
This CL estimates the sizes of the important managed objects in WASM: the decoded module {WasmModule}, the native module that contains code {NativeModule}, and the natively-allocated indirect and import tables {WasmInstanceNativeAllocations}. Since Managed<T> updates the isolate's external allocated memory, it is no longer necessary to do so upon committing or releasing a native module's memory. R=mstarzinger@chromium.org CC=ulan@chromium.org Bug: v8:7424 Change-Id: Iff4e07d0d328383a925febd654ccbfc95f0930e9 Reviewed-on: https://chromium-review.googlesource.com/1079067 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53675}
-
Michael Starzinger authored
This limits the call targets of {WasmCode} to only reference a limited set of builtins via the {RelocInfo::CODE_TARGET} relocation mode. By now most calls have been made independent of the Isolate. R=clemensh@chromium.org BUG=v8:7424 Change-Id: If4c643a7104e2ff0536ceb0f0de7fd30a923d854 Reviewed-on: https://chromium-review.googlesource.com/1092576Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53665}
-
- 11 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
The current implementation allocates a new {NativeModule} if trap handlers are disabled. Afterwards, all export wrappers need to be patched to call to the code objects in this new native module (this patching is done in {CodeSpecialization}). With the jump table, we want to get rid of this patching, hence we need to reuse the same jump table, hence we cannot allocate a new {NativeModule}. Instead, we should update the existing one with the new code. R=mstarzinger@chromium.org CC=eholk@chromium.org Bug: v8:7143, v8:7758 Change-Id: If2f395d462752b9084ed1e5f0a81f71d400ccfca Reviewed-on: https://chromium-review.googlesource.com/1095262Reviewed-by:
Eric Holk <eholk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53645}
-
- 08 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
Since we never extract pools from a {DisjointAllocationPool}, the {Allocate} method can just return an {AddressRange}, and also {Merge} just needs to merge a single {AddressRange}. Drive-by: Make {AddressRange} a proper struct, for DCHECKs and better accessors. R=mstarzinger@chromium.org Bug: v8:7754 Change-Id: I19fd02b2c6d8eb5316a5e994835b89be9cfa792b Reviewed-on: https://chromium-review.googlesource.com/1090723 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53610}
-
- 07 Jun, 2018 1 commit
-
-
Eric Holk authored
This CL adds the simplest version of a trap handler fallback. At instantiation time, we check whether the module was compiled to use trap handlers and the memory is guarded. If the memory is not guarded but the module is supposed to use trap handlers, we recompile the module with bounds checks so that we can use an unguarded memory. The compiled module is replaced with a bounds checking version, meaning future instances from this module will also use bounds checks. Some likely desirable features that are current missing but can be added future CLs include: * Disabling trap handler mode entirely. * Recompiling all old instances so that trap handler and bounds checked code does not coexist in the same process. Bug: v8:7143 Change-Id: I161fc0d544133b07dc4a93cc6af813369aaf3efe Reviewed-on: https://chromium-review.googlesource.com/1018182 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#53566}
-
- 06 Jun, 2018 1 commit
-
-
Michael Starzinger authored
This avoids embedding {RelocInfo::CODE_TARGET} addresses into WasmCode by calling a WebAssembly runtime stub instead. The stubs themselves are not yet independent of the Isolate, but will be made so soon. Note that this also introduces a proper {compiler::TrapId} to avoid accidental parameter type confusion with {TrapIf} and {TrapUnless} operators. R=clemensh@chromium.org BUG=v8:7424 Change-Id: I32ef5a1253f336fc739d2192247826e9458456df Reviewed-on: https://chromium-review.googlesource.com/1086937Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53557}
-
- 04 Jun, 2018 3 commits
-
-
Clemens Hammacher authored
The slots for imported functions are unused by now. Shrink the table to only store pointers for non-imported functions (i.e. wasm functions defined in this module). R=mstarzinger@chromium.org Change-Id: I6d13f889528b42beca73c860a800bde7a8e921ab Reviewed-on: https://chromium-review.googlesource.com/1084845Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53493}
-
Clemens Hammacher authored
1) The code table never grows, so store it in a heap-allocated byte array instead of an std::vector. 2) Rename {functions_count} to {num_functions} for consistency with {num_imported_functions} and occurences in other data structures. R=mstarzinger@chromium.org Bug: v8:7754 Change-Id: Id9d66545ed7aa675d663dad5936a9ef6d44ace7d Reviewed-on: https://chromium-review.googlesource.com/1066014 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53488}
-
Michael Starzinger authored
This makes stack checks in WasmCode independent of the underlying Isolate by loading the limit address from the WasmInstanceObject instead of embedding it into the instruction stream. It hence removes the last use of the Isolate field from WasmGraphBuilder. Additionally this introduces the notion of a "runtime stub" which represents stub code global to the NativeModule that can be directly called from each WasmCode in the same module. These stubs can act as trampolines via which Isolate-independent WasmCode can enter other V8 builtins or runtime functions that remain Isolate-dependent. They will eventually replace the current "trampoline" in a NativeModule. R=titzer@chromium.org BUG=v8:7424 Change-Id: Ie1f5582ee656b1ab7716ea06316d6e21a0268e74 Reviewed-on: https://chromium-review.googlesource.com/1078732 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#53487}
-
- 24 May, 2018 1 commit
-
-
Michael Starzinger authored
The RelocInfo::RUNTIME_ENTRY relocation mode is only used for deopt points in JavaScript code and should never appear in WebAssembly code. R=titzer@chromium.org Change-Id: Ied1d61e2b1eb886565d13448442dd6a6ed35d3f0 Reviewed-on: https://chromium-review.googlesource.com/1070197Reviewed-by:
Ben Titzer <titzer@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53340}
-
- 18 May, 2018 1 commit
-
-
Clemens Hammacher authored
When processing imports of an instance, we were storing pointers to exported (and re-imported) wasm functions in the code table of the importing module. This is dangerous since imports are instance specific. Avoid ever storing call targets for imports in the NativeModule. Instead, read the call targets from the imports table of the instance. R=mstarzinger@chromium.org Bug: chromium:843563 Change-Id: Id9f43a6c127025a5feaa81b2be75c001bc0bea81 Reviewed-on: https://chromium-review.googlesource.com/1065774 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#53256}
-
- 16 May, 2018 1 commit
-
-
Clemens Hammacher authored
In the context of launching Liftoff, this will help us estimate the code size increase and find a good value for the maximum allowed code space. R=titzer@chromium.org Bug: v8:6600 Change-Id: Ie76172edbf136629636911fe97c7ecdc940be86d Reviewed-on: https://chromium-review.googlesource.com/1061497 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53220}
-