- 18 Jun, 2018 1 commit
-
-
Clemens Hammacher authored
We currently store the {WasmModule} (generated during decoding) in a unique_ptr and pass ownership to the {WasmModuleObject} after compilation. I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to {WasmModuleObject}, which will force us to create the {WasmModuleObject} *before* compilation, so that the {CompilationState} is available during compilation. This CL prepares that refactoring by storing the {WasmModule} in a {shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be stored in a {shared_ptr} in the {Managed} anyway. R=titzer@chromium.org Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a Reviewed-on: https://chromium-review.googlesource.com/1104117 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#53801}
-
- 30 Apr, 2018 1 commit
-
-
Marja Hölttä authored
BUG=v8:7490,v8:7570 Change-Id: I74fa43a747b0d399c700acc43eb82e15ea90ba16 Reviewed-on: https://chromium-review.googlesource.com/1032736Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#52876}
-
- 18 Jan, 2018 1 commit
-
-
Ben L. Titzer authored
This is a further step to separate the implementation of the JavaScript API from the internals of the WASM implementation. Now, wasm-js.cc only needs to interact with the WASM engine and is (almost) independent of module-decoder.h and module-compiler.h. Also, move SyncCompileAndInstantiate() into wasm-module-runner.cc. Bug: v8:7316 R=clemensh@chromium.org, mstarzinger@chromium.org Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: I7765af54ac16f53a5ff88c17a22c5d36bacaf926 Reviewed-on: https://chromium-review.googlesource.com/870871 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@{#50679}
-
- 11 Oct, 2017 1 commit
-
-
Ben L. Titzer authored
R=clemensh@chromium.org Bug: Change-Id: I54e4d02cd5665d3ba3fd2e91da05599a915c0317 Reviewed-on: https://chromium-review.googlesource.com/712654Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48457}
-
- 07 Sep, 2017 1 commit
-
-
Andreas Haas authored
The wasm-async fuzzer uses the bytes provided by the fuzzer engine directly as wasm module bytes, compiles them with async compilation, and then tries to execute the "main" function of the module. This "main" can have an infinite loop which causes a timeout in the fuzzer. With this CL the "main" function is first executed with the interpreter. If the execution in the interpreter finishes within 16k steps, which means that there is no infinite loop, also the compiled code is executed. I added the raw fuzzer input as a test case because in this case I really want to test the fuzzer and not V8. R=clemensh@chromium.org Bug: chromium:761784 Change-Id: Id1fe5da0da8670ec821ab9979fdb9454dbde1162 Reviewed-on: https://chromium-review.googlesource.com/651046 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#47874}
-
- 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}
-
- 29 Jun, 2017 1 commit
-
-
Clemens Hammacher authored
In our internal code, we should only use pending exceptions. They will be converted to scheduled exceptions on the API boundary. Hence, the ErrorThrower just sets a pending exception; it should never have to think about scheduled exceptions. The new ScheduledErrorThrower inherits from ErrorThrower and reschedules any pending exceptions in its destructor (turning them into scheduled exceptions). In some situations, there might already be a scheduled exception, e.g. when calling other API methods (v8::Value::Get). In this case, the ErrorThrower should also not set another pending exception. For the reasons mentioned above, this can only be handled in the ScheduledErrorThrower, which is used the API methods. This fixes one DCHECK failure and one TODO about scheduled exceptions if no instance can be created, because the start function throws. R=mtrofin@chromium.org, mstarzinger@chromium.org BUG=v8:6232,chromium:736256 Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2 Reviewed-on: https://chromium-review.googlesource.com/548641 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Reviewed-by:
Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#46314}
-
- 21 Jun, 2017 1 commit
-
-
Andreas Haas authored
The fuzzer has already been removed from chromium. In addition I removed code which was only used by this fuzzer. BUG=chromium:734550 R=clemensh@chromium.org CC=mstarzinger@chromium.org Change-Id: I2ff4614e4d64131412ead759318e5c38e38f5d3d Reviewed-on: https://chromium-review.googlesource.com/542816 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#46078}
-
- 12 Jun, 2017 3 commits
-
-
Clemens Hammacher authored
This method is dead now (after https://chromium-review.googlesource.com/529844 and https://chromium-review.googlesource.com/529210). R=ahaas@chromium.org BUG=v8:6474 Change-Id: Icd355283312bfae712c0db61bb5049925762060b Reviewed-on: https://chromium-review.googlesource.com/530312Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45861}
-
Clemens Hammacher authored
This is a testing-only function, which is semantically equivalent to a SyncCompile followed by SyncInstantiate. We add a new SyncCompileAndInstantiate function to do those two steps in one go, and use this method instead. For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is introduced. This is part of our effort to reduce the number of special paths for testing. It is connected with https://chromium-review.googlesource.com/529210, but should not conflict with it. After landing both CLs, we can later also get rid of InstantiateModuleForTesting. R=ahaas@chromium.org, mtrofin@chromium.org BUG=v8:6474 Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc Reviewed-on: https://chromium-review.googlesource.com/529844Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45852}
-
Andreas Haas authored
This CL removes unnecessary code duplication in the fuzzer code. Instead of having special testing functions to compile and instantiate a WebAssembly module, we now just call SyncCompile and SyncInstantiate. This also fixed a problem when the fuzzer generated a GrowMemory instruction. BUG=v8:6474 R=clemensh@chromium.org Change-Id: I5f2f23349b5866ea67be20a0826271791e1a013e Reviewed-on: https://chromium-review.googlesource.com/529210 Commit-Queue: Andreas Haas <ahaas@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45851}
-
- 08 May, 2017 1 commit
-
-
Clemens Hammacher authored
Make ModuleResult and FunctionResult return Result<std::unique_ptr<X>>. This makes memory ownership and transfer of ownership more clear and avoids a lot of manual releases of the referenced native heap object. R=ahaas@chromium.org Change-Id: I7a3f5bd7761b6ae1ebdc7d17ff1b96a8df599871 Reviewed-on: https://chromium-review.googlesource.com/498352Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#45160}
-
- 27 Jan, 2017 1 commit
-
-
marja authored
These headers only need forward declarations. BUG=v8:5294 Review-Url: https://codereview.chromium.org/2654253002 Cr-Commit-Position: refs/heads/master@{#42740}
-
- 30 Nov, 2016 1 commit
-
-
clemensh authored
These byte pointers (module_start and module_end) were only valid during decoding. During instantiation or execution, they can get invalidated by garbage collection. This CL removes them from the WasmModule struct, and introduces a new ModuleStorage struct as interface to the wasm wire bytes. Since the storage is often needed together with the ModuleEnv, a new ModuleStorageEnv struct holds both a ModuleEnv and a ModuleStorage. The pointers in the ModuleStorage should never escape the live range of this struct, as they might point into a SeqOneByteString or ArrayBuffer. Therefore, the WasmInterpreter needs to create its own copy of the whole module. Runtime functions that previously used the raw pointers in WasmModule (leading to memory errors) now have to use the SeqOneByteString in the WasmCompiledModule. R=titzer@chromium.org BUG=chromium:669518 Review-Url: https://codereview.chromium.org/2540133002 Cr-Commit-Position: refs/heads/master@{#41388}
-
- 16 Nov, 2016 1 commit
-
-
titzer authored
R=clemensh@chromium.org,mtrofin@chromium.org BUG= Review-Url: https://codereview.chromium.org/2510673002 Cr-Commit-Position: refs/heads/master@{#41043}
-
- 14 Nov, 2016 1 commit
-
-
ahaas authored
This CL adds the function verification option to the module decoder. Therefore we can remove the verification in wasm-module-runner.cc R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2496203002 Cr-Commit-Position: refs/heads/master@{#40977}
-
- 20 Oct, 2016 1 commit
-
-
ahaas authored
The wasm specification does not fully specify the binary representation of NaN: the sign bit can be non-deterministic. The wasm-code fuzzer found a test case where the wasm interpreter and the compiled code produce a different sign bit for a NaN, and as a consequence they produce different results. With this CL the interpreter tracks whether it executed an instruction which can produce a NaN, which are div and sqrt instructions. The fuzzer uses this information and compares the result of the interpreter with the result of the compiled code only if there was no instruction which could have produced a NaN. R=titzer@chromium.org TEST=cctest/test-run-wasm-interpreter/TestMayProduceNaN BUG=chromium:657481 Review-Url: https://chromiumcodereview.appspot.com/2438603003 Cr-Commit-Position: refs/heads/master@{#40474}
-
- 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}
-
- 13 Oct, 2016 1 commit
-
-
ahaas authored
Stack checks in loops allows to interrupt loops. BUG=cctest/test-run-wasm-module/TestInterruptLoop R=titzer@chromium.org, bradnelson@chromium.org Review-Url: https://codereview.chromium.org/2405293002 Cr-Commit-Position: refs/heads/master@{#40251}
-
- 28 Sep, 2016 1 commit
-
-
gdeepti authored
- Store instruction with an offset bigger than GrowMemory offset should handle out of bounds correctly - Refactor to separate runnning from compile so arguments can be passed in to module builder tests. BUG=chromium:644670 R=ahaas@chromium.org, titzer@chromium.org Review-Url: https://codereview.chromium.org/2373613004 Cr-Commit-Position: refs/heads/master@{#39840}
-
- 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}
-
- 17 Sep, 2016 1 commit
-
-
gdeepti authored
test-run-wasm-module cctests broken in debug since recent refactoring changes for moving Compilation/Instantiation off the module object (https://codereview.chromium.org/2320723005). The problem here is that SetupIsolateForWasm tries to add the same property to a module_object multiple times and hits a DCHECK when this property is found on a lookup. - Fixed to use the setup method only once when CcTest::InitIsolateOnce is used. - Move setup method to test as this is only used for cctests/fuzzers. The install method should take care of this in the regular JS pipeline. R=mtrofin@chromium.org, ahaas@chromium.org Review-Url: https://codereview.chromium.org/2342263002 Cr-Commit-Position: refs/heads/master@{#39484}
-
- 15 Sep, 2016 1 commit
-
-
mtrofin authored
All parameters passed by reference must be labeled const. If the object is mutable, then we pass by pointer. BUG= Review-Url: https://codereview.chromium.org/2336233006 Cr-Commit-Position: refs/heads/master@{#39451}
-
- 14 Sep, 2016 1 commit
-
-
ahaas authored
The wasm-module-runner is used both in cctests and in fuzzers. As discussed offline, it is weird to include cctest header files in fuzzers, so I introduce a new test/common directory which contains the common files. R=titzer@chromium.org, jochen@chromium.org Review-Url: https://codereview.chromium.org/2335193002 Cr-Commit-Position: refs/heads/master@{#39411}
-
- 12 Sep, 2016 2 commits
-
-
mtrofin authored
Moved the compilation/instantiation pipeline to work off the module object (JSObject), making the compiled module data (the FixedArray) an implementation detail. This: - simplifies the code by removing duplicate decode->compile->instantiate sequences - sets up the stage for "dressing up" the runtime model with stronger typed APIs - helps relanding this CL: https://codereview.chromium.org/2305903002/. It turns out that GCs during the cloning/instantiation events cause trouble, and centering the source of truth on the module object helps address this issue. In the process, clarified cctest setup for wasm-capable isolates, and changed signatures for consistency (using ModuleOrigin througout). BUG= Review-Url: https://codereview.chromium.org/2320723005 Cr-Commit-Position: refs/heads/master@{#39360}
-
ahaas authored
With this CL the wasm-code-fuzzer first decodes and interprets the test case generated by the fuzzer. It then compiles the test case, but only executes the compiled instance if the interpretation of the test case was successful. If the compiled instance is executed, then the result of the execution is compared with the result of the interpretation. Additionally this CL refactors the CompileAndRunWasmModule function in wasm-module.cc to resuse code in the call to the interpreter. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2321443002 Cr-Commit-Position: refs/heads/master@{#39351}
-