1. 23 May, 2019 1 commit
  2. 22 May, 2019 1 commit
  3. 15 Mar, 2019 1 commit
  4. 09 Aug, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Add WasmFeatures to enable/detect features · 6aa2a253
      Ben L. Titzer authored
      This CL introduces a set of configuration options implemented as
      a struct of booleans that together comprise the set of enabled
      or detected features. The configuration options replace command-line
      flags that were checked deep in the implementation. As such, it is
      necessary to plumb them through multiple levels of abstraction.
      
      R=ahaas@chromium.org
      CC=mstarzinger@chromium.org
      BUG=chromium:868844
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
      Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55018}
      6aa2a253
  5. 21 Jun, 2018 1 commit
  6. 09 Apr, 2018 1 commit
  7. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  8. 18 Jan, 2018 1 commit
  9. 28 Sep, 2017 1 commit
  10. 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
  11. 12 Jun, 2017 2 commits
  12. 24 Jan, 2017 1 commit
  13. 23 Jan, 2017 1 commit
    • ahaas's avatar
      [wasm] Change the constant kV8MaxWasmMemoryPages to a command line flag. · 94266b7d
      ahaas authored
      The hardcoded constant caused a problem for the wasm fuzzer because
      when the maximum memory was allocated in a test case, clusterfuzz ran
      out of memory. with the command line flag we can set a lower limit
      for the fuzzer.
      
      The flag has the value of the constant as its default value, so that
      for everything but the fuzzers nothing should change.
      
      R=titzer@chromium.org
      BUG=chromium:676888
      
      Review-Url: https://codereview.chromium.org/2626313003
      Cr-Commit-Position: refs/heads/master@{#42599}
      94266b7d
  14. 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
  15. 14 Sep, 2016 1 commit
  16. 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
  17. 22 Jun, 2016 1 commit
  18. 03 Mar, 2016 1 commit
  19. 02 Mar, 2016 1 commit
  20. 02 Feb, 2016 1 commit