1. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store WasmModule in shared_ptr during async compilation · 6be6ec00
      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: 's avatarBen Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53801}
      6be6ec00
  2. 30 Apr, 2018 1 commit
  3. 18 Jan, 2018 1 commit
  4. 11 Oct, 2017 1 commit
  5. 07 Sep, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Avoid executing infinite loops in the wasm fuzzers · 7b53a0e0
      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: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47874}
      7b53a0e0
  6. 18 Jul, 2017 1 commit
  7. 29 Jun, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] Use pending exceptions consistently · d6aed443
      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: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#46314}
      d6aed443
  8. 21 Jun, 2017 1 commit
  9. 12 Jun, 2017 3 commits
  10. 08 May, 2017 1 commit
  11. 27 Jan, 2017 1 commit
  12. 30 Nov, 2016 1 commit
    • clemensh's avatar
      [wasm] Remove raw byte pointers from WasmModule · 6572b562
      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}
      6572b562
  13. 16 Nov, 2016 1 commit
  14. 14 Nov, 2016 1 commit
  15. 20 Oct, 2016 1 commit
    • ahaas's avatar
      [wasm] Track in the interpreter if a NaN could have been produced. · 57b14b06
      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}
      57b14b06
  16. 19 Oct, 2016 1 commit
    • titzer's avatar
      [wasm] Use a Managed<WasmModule> to hold metadata about modules. · 418b239f
      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}
      418b239f
  17. 13 Oct, 2016 1 commit
  18. 28 Sep, 2016 1 commit
  19. 20 Sep, 2016 1 commit
  20. 17 Sep, 2016 1 commit
    • gdeepti's avatar
      [wasm] Fix test-run-wasm-module tests in debug mode. · dd3b14b7
      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}
      dd3b14b7
  21. 15 Sep, 2016 1 commit
  22. 14 Sep, 2016 1 commit
  23. 12 Sep, 2016 2 commits
    • mtrofin's avatar
      [wasm] Compilation/Instantiation pipeline works off module object · 8e5ac62d
      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}
      8e5ac62d
    • ahaas's avatar
      [wasm] Call the wasm interpreter from the wasm-code-fuzzer. · 1521fe9c
      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}
      1521fe9c