- 18 Nov, 2019 1 commit
-
-
Z Nguyen-Huu authored
We detect a stepping in Wasm from Javascript into Wasm then prepare the target function for debugging. The trick is redirect the target to interpreter and set a 'fake' breakpoint in the first instruction. Currently we don't need to clear this 'fake' breakpoint since it won't notify unless user intend to step in. Change-Id: Ibe1f9ba31dc6c7919895d3fe31967e9c4699ef63 Bug: chromium:1019606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1902259 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#65020}
-
- 24 Oct, 2019 1 commit
-
-
Clemens Backes authored
This will allow us to reuse this method in other contexts. This CL also contains smaller refactorings that helped to move the code. E.g. the WASMVALUE_CTYPES macro (defined in value-type.h) replaces the WASM_CTYPES macro (from wasm-interpreter.cc). R=mstarzinger@chromium.org Bug: v8:9676 Change-Id: Id788f843af9a09eb940593afa1639f12b652c514 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876054 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64534}
-
- 21 Oct, 2019 1 commit
-
-
Clemens Backes authored
The MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR macro defines a defaulted move constructor and move-assignment operator. The {std::unique_ptr} on the other hand needs the contained type to be complete when instantiating the move assignment operator. Hence, this fails e.g. on MSVC, see https://github.com/nodejs/node/pull/30020#issuecomment-544485991. It turns out that we never actually move the interpreter, so we can just replace the MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR by DISALLOW_COPY_AND_ASSIGN. R=ahaas@chromium.org Change-Id: Iba7d30243510ed9554be62b0c4c8e6f47f0c3307 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871921Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64423}
-
- 16 Oct, 2019 1 commit
-
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: I2eb419bbfbea81d58b1c13e527af1728d84c4092 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864656Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64329}
-
- 26 Sep, 2019 1 commit
-
-
Clemens Backes authored
R=adamk@chromium.org No-Try: true Change-Id: I71824f52802c125dbee51216054575f44d08d534 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1825243 Commit-Queue: Clemens Backes [né Hammacher] <clemensb@chromium.org> Auto-Submit: Clemens Backes [né Hammacher] <clemensb@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#63983}
-
- 17 Sep, 2019 1 commit
-
-
Andreas Haas authored
For unknown reasons, WasmInterpreterInternals was a zone object. However WasmInterpreterInternals indirectly owns a global handle and a unique_ptr, both for the interpreter stack. As a zone object, WasmInterpreterInternals is never destructed, and therefore never frees the unique_ptr. With this CL I make WasmInterpreterInternals a normal object and allocate it into a unique_ptr, so that it gets destructed properly. R=mstarzinger@chromium.org Bug: chromium:1000610 Change-Id: Ie08c5627393a434521f5c32702bf9945db2c7811 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1807361Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#63835}
-
- 13 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
After https://crrev.com/c/1800575 and https://crrev.com/c/1803343, which tried to fix this on occuring compile errors, this CL systematically adds the <memory> include to each header that uses {std::unique_ptr}. R=sigurds@chromium.org TBR=mlippautz@chromium.org,alph@chromium.org,rmcilroy@chromium.org,verwaest@chromium.org Bug: v8:9396 Change-Id: If7f9c3140842f9543135dddd7344c0f357999da0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803349Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#63767}
-
- 10 May, 2019 1 commit
-
-
Ben Smith authored
They are added under the global scope object, as follows: { "memory": ..., "globals": { "global#0": ..., "global#1": ..., "global#2": ..., } } We currently don't have any way to name globals in the wasm binary format, but it is possible to extend the name section with these names in the future. Bug: v8:6846 Change-Id: I79fa4ed3d83964bc8e26d66516605d41e92b3d03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1601829 Commit-Queue: Ben Smith <binji@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61425}
-
- 27 Mar, 2019 1 commit
-
-
Sigurd Schneider authored
Bug: v8:9020 Change-Id: I3a939d65ec8468f034d4670d9b14a911e5ef5a61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1541044Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#60492}
-
- 21 Mar, 2019 1 commit
-
-
Ben Smith authored
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}
-
- 12 Mar, 2019 1 commit
-
-
Frederik Gossen authored
Added a new compilation unit for Wasm interpreter in order to make it a first-class tier in the future. Adapted Wasm interpreter usage to work with the new interface. The new compilation unit is currently not used. Change-Id: Ib9e1d0dc6ca1b03467cc43059f03ce153bb96400 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1514734 Commit-Queue: Frederik Gossen <frgossen@google.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#60183}
-
- 07 Feb, 2019 1 commit
-
-
Michael Starzinger authored
This adds a test case to check consistency of how an "unreachable" trap is handled by a surrounding "try" block in case those two operations are in different functions (i.e. not local to one function body). It also fixes a DCHECK for an as-of-yet untested interpreter state transition. R=clemensh@chromium.org TEST=cctest/test-run-wasm-exceptions BUG=v8:8729 Change-Id: I432c48d0bc664f7ab092aaafef6dfa29c5f262fd Reviewed-on: https://chromium-review.googlesource.com/c/1454605 Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#59429}
-
- 03 Oct, 2018 1 commit
-
-
Hans Wennborg authored
This is part of clean-up for a new Clang warning that we'd like to enable. This patch addresses all warnings from V8 that I saw in a full debug build of Chromium on Linux. ../../v8/src/reloc-info.h:405:18: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted] RelocIterator& operator=(RelocIterator&&) = default; ^ ../../v8/src/reloc-info.h:447:13: note: move assignment operator of 'RelocIterator' is implicitly deleted because field 'mode_mask_' is of const-qualified type 'const int' const int mode_mask_; ^ ../../v8/src/wasm/baseline/liftoff-compiler.cc:111:36: warning: explicitly defaulted move constructor is implicitly deleted [-Wdefaulted-function-deleted] MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(LiftoffCompiler); ^ ../../v8/src/wasm/baseline/liftoff-compiler.cc:1834:20: note: move constructor of 'LiftoffCompiler' is implicitly deleted because field 'asm_' has a deleted move constructor LiftoffAssembler asm_; ^ ../../v8/src/wasm/wasm-debug.cc:95:3: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted] MOVE_ONLY_NO_DEFAULT_CONSTRUCTOR(InterpreterHandle); ^ ../../v8/src/wasm/wasm-debug.cc:98:19: note: move assignment operator of 'InterpreterHandle' is implicitly deleted because field 'interpreter_' has a deleted move assignment operator WasmInterpreter interpreter_; ^ ../../v8/src/wasm/wasm-interpreter.h:211:35: note: copy assignment operator of 'WasmInterpreter' is implicitly deleted because field 'internals_' is of const-qualified type 'v8::internal::wasm::WasmInterpreterInternals *const' WasmInterpreterInternals* const internals_; ^ Bug: chromium:890307 Change-Id: Idfc5827f24821212081a006c4329c466c4576bcc Reviewed-on: https://chromium-review.googlesource.com/c/1256863 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#56351}
-
- 05 Jul, 2018 1 commit
-
-
Igor Sheludko authored
Bug: v8:7754 Change-Id: Id7701375897f6f3cfac7327404751b43cfdb221c Reviewed-on: https://chromium-review.googlesource.com/1118888Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#54252}
-
- 02 May, 2018 1 commit
-
-
Marja Hölttä authored
BUG=v8:7490 Change-Id: I2a597eda708b2ea34c9e32e39556159b48591b61 Reviewed-on: https://chromium-review.googlesource.com/1039196Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#52911}
-
- 06 Apr, 2018 1 commit
-
-
Ben L. Titzer authored
This change makes lifetime management of WasmCode much simpler. By using the WasmInstanceObject as the context for WASM code execution, including the pointer to the memory base and indirect function tables, this keeps the instance alive when WASM code is on the stack, since the instance object is passed as a parameter and spilled onto the stack. This is in preparation of sharing the code between instances and isolates. Bug: v8:7424 R=mstarzinger@chromium.org Change-Id: Ia35a3ce91a8f6135767fa764e185cde8bbc889f4 Reviewed-on: https://chromium-review.googlesource.com/997932 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#52436}
-
- 04 Apr, 2018 2 commits
-
-
Ben Titzer authored
This reverts commit 57bf0bfe. Reason for revert: <INSERT REASONING HERE> Original change's description: > [wasm] Merge the WasmContext into WasmInstanceObject > > This change makes lifetime management of WasmCode much simpler. > By using the WasmInstanceObject as the context for WASM code execution, > including the pointer to the memory base and indirect function tables, > this keeps the instance alive when WASM code is on the stack, since > the instance object is passed as a parameter and spilled onto the stack. > This is in preparation of sharing the code between instances and > isolates. > > Bug: v8:7424 > > Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e > Reviewed-on: https://chromium-review.googlesource.com/958520 > Commit-Queue: Ben Titzer <titzer@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> > Cr-Commit-Position: refs/heads/master@{#52361} TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7424 Reviewed-on: https://chromium-review.googlesource.com/995418Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52364}
-
Ben L. Titzer authored
This change makes lifetime management of WasmCode much simpler. By using the WasmInstanceObject as the context for WASM code execution, including the pointer to the memory base and indirect function tables, this keeps the instance alive when WASM code is on the stack, since the instance object is passed as a parameter and spilled onto the stack. This is in preparation of sharing the code between instances and isolates. Bug: v8:7424 Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e Reviewed-on: https://chromium-review.googlesource.com/958520 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#52361}
-
- 21 Feb, 2018 1 commit
-
-
Ben L. Titzer authored
This CL changes the WASM implementation to access indirect function tables through the WasmContext, whereas previously indirect function tables and their sizes were constants that were inlined into compiled into code, requiring code patching. This is a necessary step for sharing code between instances and eventually, isolates. R=clemensh@chromium.org,mstarzinger@chromium.org Bug: v8:7424 Change-Id: Ida4138ed92729730dfbc0a81a84d8484b233d808 Reviewed-on: https://chromium-review.googlesource.com/895683 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#51427}
-
- 02 Feb, 2018 1 commit
-
-
jgruber authored
This check verifies that all .h files in the src/ directory have an include guard of the form #ifndef V8_PATH_TO_FILE_H_ #define V8_PATH_TO_FILE_H_ // ... #endif // V8_PATH_TO_FILE_H_ The check can be skipped with a magic comment: // PRESUBMIT_INTENTIONALLY_MISSING_INCLUDE_GUARD Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I0a7b96abec289ad60f64ba8418f1892a6969596d Reviewed-on: https://chromium-review.googlesource.com/897487Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#51079}
-
- 20 Dec, 2017 1 commit
-
-
Clemens Hammacher authored
We were passing a pointer to an object allocated as {InterpretedFrameImpl} in an {std::unique_ptr<InterpretedFrame>}. The default deleter then called {delete ptr;} on a ptr of type {InterpretedFrame*}, even though that object was allocated as {InterpretedFrameImpl}. This error might caught by validators. Fix this by passing a custom deleter on the unique_ptr. R=ahaas@chromium.org, ulan@chromium.org Bug: v8:7231 Change-Id: Ia18114236384813c4878319209ae4535fda56c41 Reviewed-on: https://chromium-review.googlesource.com/834510Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#50226}
-
- 16 Oct, 2017 1 commit
-
-
Ben L. Titzer authored
With the introduction of the WasmContext, compiled code is no longer specialized to the memory start and size (or recently, globals_start). This CL uses the same WasmContext between the interpreter and compiled code, removing the need for UpdateMemory() and cached instance info. R=clemensh@chromium.org Bug: Change-Id: I0bd52352c9b6f3029246e94e239dc29f635e7920 Reviewed-on: https://chromium-review.googlesource.com/712734 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#48584}
-
- 07 Aug, 2017 1 commit
-
-
Mircea Trofin authored
This is part of the effort to consolidate the ownership of wasm instantiation/specialization parameters. This change is focused solely on the interpreter part of that effort, to verify we're not regressing performance in interpreter benchmarks. There are two aspects being addressed: - dataflow-wise, we always fetch the interpreter's memory view from the runtime objects (i.e. WasmInstanceObject/WasmCompiledModule). This is consistent with how other instance-specific information is obtained (e.g. code, indirect functions). - representation-wise, we do not reuse ModuleEnv/WasmInstance just for the memory view, because it is surprising that other instance info isn't accessed from there. Bug: Change-Id: I536fbffd8e1f142a315fa1770ba9b08319f56a8e Reviewed-on: https://chromium-review.googlesource.com/602083Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#47205}
-
- 18 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
This allows to reuse the class e.g. in the baseline compiler. R=titzer@chromium.org Change-Id: I7251af16e8c74f267834a9cefb676edf3c9f3a07 Reviewed-on: https://chromium-review.googlesource.com/570020Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46735}
-
- 14 Jul, 2017 1 commit
-
-
Clemens Hammacher authored
This is a reland of 5648aad5. Previous compile error should be fixed by disabling strict aliasing assumptions on gyp: https://chromium-review.googlesource.com/c/571806 Original change's description: > [wasm] Don't store global handles in the interpreter > > Storing global handles in the interpreter is dangerous, because the > global handles are strong roots into the heap. The interpreter itself is > referenced from the heap via a Managed. Hence the interpreter keeps the > instance alive, while the instance keeps the Managed alive. So the GC > will never collect them. > > This CL refactors this to only store the handle to the instance object > while executing in the interpreter, and clearing it when returning. > It also removes the cache of import wrappers, as it should not be > performance critical, but keeps lots of objects alive. If it turns out > to be performance critical, we will have to reintroduce such a cache > stored in the WasmDebugInfo object. > > R=titzer@chromium.org > CC=ahaas@chromium.org > > Bug: chromium:610330 > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb > Reviewed-on: https://chromium-review.googlesource.com/567058 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46629} TBR=titzer@chromium.org Bug: chromium:610330 Change-Id: Ic7836b1b1a044a89f2138f0c76f92acd3a1b2f2b Reviewed-on: https://chromium-review.googlesource.com/570578 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46679}
-
- 13 Jul, 2017 2 commits
-
-
Clemens Hammacher authored
This reverts commit 5648aad5. Reason for revert: Compile error on mips: https://build.chromium.org/p/client.v8.ports/builders/V8%20Mips%20-%20builder/builds/10732 Original change's description: > [wasm] Don't store global handles in the interpreter > > Storing global handles in the interpreter is dangerous, because the > global handles are strong roots into the heap. The interpreter itself is > referenced from the heap via a Managed. Hence the interpreter keeps the > instance alive, while the instance keeps the Managed alive. So the GC > will never collect them. > > This CL refactors this to only store the handle to the instance object > while executing in the interpreter, and clearing it when returning. > It also removes the cache of import wrappers, as it should not be > performance critical, but keeps lots of objects alive. If it turns out > to be performance critical, we will have to reintroduce such a cache > stored in the WasmDebugInfo object. > > R=titzer@chromium.org > CC=ahaas@chromium.org > > Bug: chromium:610330 > Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb > Reviewed-on: https://chromium-review.googlesource.com/567058 > Reviewed-by: Ben Titzer <titzer@chromium.org> > Commit-Queue: Clemens Hammacher <clemensh@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46629} TBR=titzer@chromium.org,clemensh@chromium.org Change-Id: Ifadfb885f937f37bb3eab4732a97f20ff40c2583 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:610330 Reviewed-on: https://chromium-review.googlesource.com/569962Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46630}
-
Clemens Hammacher authored
Storing global handles in the interpreter is dangerous, because the global handles are strong roots into the heap. The interpreter itself is referenced from the heap via a Managed. Hence the interpreter keeps the instance alive, while the instance keeps the Managed alive. So the GC will never collect them. This CL refactors this to only store the handle to the instance object while executing in the interpreter, and clearing it when returning. It also removes the cache of import wrappers, as it should not be performance critical, but keeps lots of objects alive. If it turns out to be performance critical, we will have to reintroduce such a cache stored in the WasmDebugInfo object. R=titzer@chromium.org CC=ahaas@chromium.org Bug: chromium:610330 Change-Id: I54b489dadc16685887c0c1a98da6fd0df5ad7cbb Reviewed-on: https://chromium-review.googlesource.com/567058Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46629}
-
- 07 Jul, 2017 1 commit
-
-
titzer authored
This CL refactors the internal representation of JavaScript-exposed WebAssembly objects to be more like other such objects in V8. By introducing a new instance type for each of the JS-exposed types, we get more robust typechecking without using embedder fields (which were previously used when these objects where instance type JS_API_OBJECT). In addition to the new instance types, the subclasses X of JSObject (WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject) now have appropriate Is##X() methods on Object and are now robust. BUG=v8:6547 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng Review-Url: https://codereview.chromium.org/2964943002 Cr-Commit-Position: refs/heads/master@{#46475}
-
- 09 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
This CL removes most occurences of "WASM" from outputs and comments in the code. They are replaced either by "WebAssembly" or (especially in comments) "wasm". These are the spellings officially proposed on http://webassembly.org/. R=ahaas@chromium.org BUG=v8:6474 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Id39fa5e25591678263745a4eab266db546e65983 Reviewed-on: https://chromium-review.googlesource.com/529085Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45824}
-
- 22 May, 2017 1 commit
-
-
Wiktor Garbacz authored
Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9 Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Jochen Eisinger <jochen@chromium.org> Commit-Queue: Wiktor Garbacz <wiktorg@google.com> Cr-Commit-Position: refs/heads/master@{#45458}
-
- 28 Apr, 2017 1 commit
-
-
Clemens Hammacher authored
This reduces the amount of special paths for testing. Setup the memory used for testing exactly the same way as in real world. Also, always connect the interpreter to the instance being executed, and to the existing WasmInstance struct. This keeps information synchronized between interpreter and test runner. These changes allow us to execute e.g. GrowMemory from cctests either in the interpreter or in compiled code. R=ahaas@chromium.org Change-Id: Id4726d061f3cdba789275350f500d769d27d2d63 Reviewed-on: https://chromium-review.googlesource.com/488561 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44966}
-
- 25 Apr, 2017 1 commit
-
-
Clemens Hammacher authored
Instead of dynamically tracking the block nesting, precompute the information statically. The interpreter was already using a side table to store the pc diff for each break, conditional break and others. The information needed to adjust the stack was tracked dynamically, however. This CL also precomputes this information, as it is statically known. Instead of just storing the pc diff in the side table, we now store the pc diff, the stack height diff and the arity of the target block. Local measurements show speedups of 5-6% on average, sometimes >10%. R=ahaas@chromium.org BUG=v8:5822 Change-Id: I986cfa989aabe1488f2ff79ddbfbb28aeffe1452 Reviewed-on: https://chromium-review.googlesource.com/485482Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#44837}
-
- 12 Apr, 2017 2 commits
-
-
Clemens Hammacher authored
The local variables were parsed two times, which in fact doubled the amount of local variables allocated for each called function. This was costing memory and performance. As the additional local variables were never used, we did not recognize this before. Add a test case for locals and stack values of interpreted frames. R=ahaas@chromium.org BUG=v8:5822 Change-Id: Ie5cb8d8f5441edee6abb46aa6bebef4a033d582b Reviewed-on: https://chromium-review.googlesource.com/474749 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44602}
-
Clemens Hammacher authored
Similar to WasmInterpreter::Thread, we now also use the pimpl idiom for InterpretedFrame, hiding the implementation completely in the .cc file. This allows us to store just two things per InterpretedFrameImpl: The corresponding thread, and the frame index. The external interface changes to always return a std::unique_ptr, because the object layout is not known via the public interface, hence objects cannot be stack allocated. They also cannot be copied or passed by value. The frame inspection interface will be tested after another fix in https://chromium-review.googlesource.com/474749. R=ahaas@chromium.org BUG=v8:5822 Change-Id: I7b109da73df745fac97ec72cb0cf4f0ad71e5da9 Reviewed-on: https://chromium-review.googlesource.com/472887Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#44600}
-
- 06 Apr, 2017 1 commit
-
-
Clemens Hammacher authored
The Run() method ran in chunks of {kRunSteps} steps till completion or breakpoint, while Step() executed exactly one step. This CL removes the {kRunSteps} concept, and instead allows to pass the number of steps to run to the Run() method. Step() just calls Run(1). R=ahaas@chromium.org BUG=chromium:708457,v8:5822 Change-Id: I03f7f4da4e0d0e72337399206f1c49ff0f1f041a Reviewed-on: https://chromium-review.googlesource.com/469846 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44443}
-
- 23 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
This CL adds support for indirect function calls to the interpreter. It can indirectly call other wasm function in the same instance, which are then executed in the interpreter, or call imported functions. Implementing this required some refactoring: - The wasm interpreter now unwraps import wrappers on demand, instead of unwrapping all of them on instantiation and storing a vector of handles. This also avoids the DeferredHandleScope completely, instead we just store two global handles in the code map. - The interpreter gets the code table, function tables and signature tables directly from the attached wasm instance object. This ensures that the interpreter sees all updates to tables that might have been performed by external code. - There is now common functionality for calling a code object. This is used for direct calls to imported functions and for all indirect calls. As these code objects can also be wasm functions which should be executed in the interpreter itself, I introduce a struct to hold the outcome of calling the code object, or a pointer to InterpreterCode to be called in the interpreter. R=ahaas@chromium.org BUG=v8:5822 Change-Id: I20fb2ea007e79e5fcff9afb4b1ca31739ebcb83f Reviewed-on: https://chromium-review.googlesource.com/458417 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44059}
-
- 21 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
This CL makes the interpreter reentrant by allowing different activations to be live at the same time. The wasm interpreter keeps a list of activations and stores the stack height at the start of each activation. This information is used to unwind just one activation, or show the right portion of the interpreter stack for each interpreter entry frame. The WasmDebugInfo object stores a mapping from frame pointer (of the interpreter entry) to the activation id in order to identify the activation based on the physical interpreter entry frame. R=titzer@chromium.org, ahaas@chromium.org BUG=v8:5822 Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb Reviewed-on: https://chromium-review.googlesource.com/453958 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43976}
-
- 20 Mar, 2017 1 commit
-
-
Clemens Hammacher authored
If an exception is thrown and the wasm interpreter entry frame is unwound, also the internal frames in the interpreter need to be unwound. We did not do so before, leaving a corrupted internal state of the wasm interpreter. Thus reusing it would fail. This CL fixes this and adds a test which reenters a previously unwound wasm interpreter. It checks that this works and the correct stack is returned. This test also requires support for calling an imported function which throws, so this change is also included here. R=ahaas@chromium.org, titzer@chromium.org BUG=v8:5822 Change-Id: I12fb843f7a371a4e618b4ac63ed3299667a03a82 Reviewed-on: https://chromium-review.googlesource.com/453938 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43937}
-
- 16 Mar, 2017 2 commits
-
-
Clemens Hammacher authored
This behaviour was missing before. If a trap is encountered in the interpreter, we now throw the right error. With test. R=titzer@chromium.org, ahaas@chromium.org BUG=v8:5822 Change-Id: I09c23d15fcde32ec586fb6d3094a5ec49155a9a2 Reviewed-on: https://chromium-review.googlesource.com/453839 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43859}
-
Clemens Hammacher authored
When instantiating the wasm interpreter for debugging, we unwrap all wasm-to-js wrappers and store the callable objects. The handles are stored in a DeferredHandleScope and deleted when the InterpreterHandle (store in WasmDebugInfo) is freed. A call to an imported function reads the arguments from the stack, converts them to JS objects, calls the callable, converts back the return value and pushes it onto the stack. Reentering the interpreter from the calles JS code is not permitted yet, but will be in a follow-up CL. Also, indirect calls to imported functions will have to follow. R=titzer@chromium.org, ahaas@chromium.org BUG=v8:5822 Change-Id: I66c35053bccb6cf8d416606e4f840d888ccb3b65 Reviewed-on: https://chromium-review.googlesource.com/453838 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#43855}
-