1. 15 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [base] Introduce VectorOf helper · 3ad032b7
      Clemens Hammacher authored
      We often need to create a {Vector} view of data owned by a container
      like {std::vector}. The canonical way to do this is this:
      Vector<T>{vec.data(), vec.size()}
      
      This pattern is repeating information which can be deduced
      automatically, like the type T.
      
      This CL introduces a {VectorOf} helper which can construct a {Vector}
      for any container providing a {data()} and {size()} accessor, and uses
      it to replace the pattern above.
      
      R=ishell@chromium.org
      
      Bug: v8:8238
      Change-Id: Ib3a11662acc82cb83f2b4afd07ba88e579d71dba
      Reviewed-on: https://chromium-review.googlesource.com/c/1337584Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57538}
      3ad032b7
  2. 12 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Reset StreamingProcessor on error · 3b64603d
      Clemens Hammacher authored
      After the first decoder error, the streaming processor should not be
      called again. To enforce this, reset the {processor_} field. This also
      makes the {ok_} field redundant.
      Note that this refactoring is also necessary for a future CL which
      makes the {StreamingProcessor} keep the {AsyncCompileJob} alive. By
      resetting the processor, we also remove that link.
      
      R=ahaas@chromium.org
      
      Bug: v8:7921
      Change-Id: I42f5ed26a8f26c3dc8db5676557a0d82021e132e
      Reviewed-on: https://chromium-review.googlesource.com/c/1329179
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57435}
      3b64603d
  3. 12 Jul, 2018 1 commit
  4. 27 Jun, 2018 3 commits
  5. 22 Jun, 2018 1 commit
  6. 28 Nov, 2017 3 commits
    • Mircea Trofin's avatar
      Revert "Revert "[wasm] JIT using WasmCodeManager"" · b03b1bd9
      Mircea Trofin authored
      This reverts commit b301203e.
      
      Reason for revert: Fixed issues on arm.
      
      Original change's description:
      > Revert "[wasm] JIT using WasmCodeManager"
      > 
      > This reverts commit d4c8393c.
      > 
      > Reason for revert: Breaks ARM hardware:
      > https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
      > 
      > Original change's description:
      > > [wasm] JIT using WasmCodeManager
      > > 
      > > This is the first step towards wasm code sharing. This CL moves wasm
      > > code generation outside the JavaScript GC heap using the previously -
      > > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      > > flag).
      > > 
      > > See design document: go/wasm-on-native-heap-stage-1
      > > 
      > > This CL doesn't change other wasm architectural invariants. We still
      > > have per-Isolate wasm code generation, and per-wasm module instance
      > > code specialization.
      > > 
      > > Bug:v8:6876
      > > 
      > > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      > > Reviewed-on: https://chromium-review.googlesource.com/674086
      > > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > > Reviewed-by: Eric Holk <eholk@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#49689}
      > 
      > TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      > 
      > Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
      > No-Presubmit: true
      > No-Tree-Checks: true
      > No-Try: true
      > Bug: v8:6876
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/794690
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49691}
      
      TBR=bradnelson@chromium.org,machenbach@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: I1b07638d1bb2ba0664305b4b2dcfc1342dc8444f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6876
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/794434
      Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49692}
      b03b1bd9
    • Michael Achenbach's avatar
      Revert "[wasm] JIT using WasmCodeManager" · b301203e
      Michael Achenbach authored
      This reverts commit d4c8393c.
      
      Reason for revert: Breaks ARM hardware:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Arm%20-%20debug/builds/5268
      
      Original change's description:
      > [wasm] JIT using WasmCodeManager
      > 
      > This is the first step towards wasm code sharing. This CL moves wasm
      > code generation outside the JavaScript GC heap using the previously -
      > introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      > flag).
      > 
      > See design document: go/wasm-on-native-heap-stage-1
      > 
      > This CL doesn't change other wasm architectural invariants. We still
      > have per-Isolate wasm code generation, and per-wasm module instance
      > code specialization.
      > 
      > Bug:v8:6876
      > 
      > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      > Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      > Reviewed-on: https://chromium-review.googlesource.com/674086
      > Reviewed-by: Ben Titzer <titzer@chromium.org>
      > Reviewed-by: Eric Holk <eholk@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49689}
      
      TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,eholk@chromium.org
      
      Change-Id: I89af1ea5decd841bc12cd2ceaf74d32bc4433885
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:6876
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/794690Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49691}
      b301203e
    • Mircea Trofin's avatar
      [wasm] JIT using WasmCodeManager · d4c8393c
      Mircea Trofin authored
      This is the first step towards wasm code sharing. This CL moves wasm
      code generation outside the JavaScript GC heap using the previously -
      introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
      flag).
      
      See design document: go/wasm-on-native-heap-stage-1
      
      This CL doesn't change other wasm architectural invariants. We still
      have per-Isolate wasm code generation, and per-wasm module instance
      code specialization.
      
      Bug:v8:6876
      
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
      Reviewed-on: https://chromium-review.googlesource.com/674086Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49689}
      d4c8393c
  7. 19 Oct, 2017 1 commit
  8. 18 Oct, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[test] Avoid unnecessary std::vector allocations" · ab639e4a
      Clemens Hammacher authored
      This reverts commit e737b4ce.
      
      Reason for revert: On windows, V8_INFINITY is not constexpr
      
      Original change's description:
      > [test] Avoid unnecessary std::vector allocations
      > 
      > Instead of copying an array of fixed values into an std::vector for
      > each usage of the FOR_INPUTS macro, just iterate the constant data
      > directly.
      > This also makes the <type>_vector() functions return {constexpr Vector}
      > instead of {std::vector}.
      > 
      > R=​tebbi@chromium.org
      > 
      > Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
      > Reviewed-on: https://chromium-review.googlesource.com/725427
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48688}
      
      TBR=clemensh@chromium.org,tebbi@chromium.org
      
      Change-Id: Iccb52941d4efe71b49b41572c3d922a5d78bdfd2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/725899Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48691}
      ab639e4a
    • Clemens Hammacher's avatar
      [test] Avoid unnecessary std::vector allocations · e737b4ce
      Clemens Hammacher authored
      Instead of copying an array of fixed values into an std::vector for
      each usage of the FOR_INPUTS macro, just iterate the constant data
      directly.
      This also makes the <type>_vector() functions return {constexpr Vector}
      instead of {std::vector}.
      
      R=tebbi@chromium.org
      
      Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
      Reviewed-on: https://chromium-review.googlesource.com/725427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48688}
      e737b4ce
  9. 13 Oct, 2017 1 commit
  10. 12 May, 2017 1 commit
  11. 04 May, 2017 1 commit
  12. 03 Mar, 2017 1 commit
    • clemensh's avatar
      [wasm] Prepare WasmCompilationUnit for lazy compilation · 7f68cbbf
      clemensh authored
      In lazy compilation, we only compile one function at a time, and we
      might not have the wire bytes of the whole module available.
      This CL prepares the WasmCompilationUnit for this setting.
      It will also be helpful for streaming compilation.
      
      Also, the ErrorThrower (which might heap-allocate) is not stored in the
      WasmCompilationUnit any more. Instead, it is passed to the
      FinishCompilation method which is allowed to heap-allocate.
      
      R=titzer@chromium.org, ahaas@chromium.org
      BUG=v8:5991
      
      Review-Url: https://codereview.chromium.org/2726553003
      Cr-Commit-Position: refs/heads/master@{#43573}
      7f68cbbf
  13. 19 Dec, 2016 1 commit
    • clemensh's avatar
      [wasm] Always provide a wasm instance object at runtime · 21a85c4a
      clemensh authored
      When executing wasm code for testing, we did not create a
      WasmInstanceObject and link it to the generated code. This required
      some special handling at runtime (mainly for stack trace generation).
      This CL always provides the WasmInstanceObject, such that e.g. function
      names can be resolved the usual way.
      The module bytes referenced by the WasmCompiledModule linked with the
      WasmInstanceObject do not hold a valid wasm module yet. Instead, we
      just add the bytes we need, and make the objects in WasmModule point to
      those bytes (currently only used for function names). Those bytes will
      not be parsed at runtime anyway.
      
      R=titzer@chromium.org
      CC=jgruber@chromium.org
      BUG=v8:5620
      
      Review-Url: https://codereview.chromium.org/2551053002
      Cr-Commit-Position: refs/heads/master@{#41809}
      21a85c4a
  14. 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
  15. 17 Oct, 2016 1 commit
  16. 26 Apr, 2016 1 commit
  17. 30 Sep, 2015 1 commit
  18. 25 Jun, 2015 1 commit
  19. 24 Jun, 2015 2 commits
  20. 10 Jun, 2015 1 commit
  21. 09 Jun, 2015 4 commits
  22. 12 Jan, 2015 1 commit
    • jochen's avatar
      Merge v8_optimized_debug 1 and 2 · aeb09e6d
      jochen authored
      All builders that used level 1 should meanwhile define
      v8_enable_slow_dchecks, and so they can use level 2 without losing
      coverage. Level 2, however, is considerably faster, so we want to use it
      on those builders as well. The make optdebug setting is not affected by
      this change.
      
      BUG=none
      R=machenbach@chromium.org
      LOG=n
      
      Review URL: https://codereview.chromium.org/847753002
      
      Cr-Commit-Position: refs/heads/master@{#26019}
      aeb09e6d
  23. 15 Oct, 2014 1 commit
  24. 10 Sep, 2014 1 commit
  25. 26 Aug, 2014 1 commit
  26. 04 Aug, 2014 1 commit
  27. 02 Jul, 2014 1 commit
  28. 03 Jun, 2014 1 commit
  29. 29 Apr, 2014 1 commit
  30. 25 Apr, 2014 2 commits