1. 19 Oct, 2017 1 commit
  2. 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
  3. 13 Oct, 2017 1 commit
  4. 12 May, 2017 1 commit
  5. 04 May, 2017 1 commit
  6. 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
  7. 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
  8. 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
  9. 17 Oct, 2016 1 commit
  10. 26 Apr, 2016 1 commit
  11. 30 Sep, 2015 1 commit
  12. 25 Jun, 2015 1 commit
  13. 24 Jun, 2015 2 commits
  14. 10 Jun, 2015 1 commit
  15. 09 Jun, 2015 4 commits
  16. 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
  17. 15 Oct, 2014 1 commit
  18. 10 Sep, 2014 1 commit
  19. 26 Aug, 2014 1 commit
  20. 04 Aug, 2014 1 commit
  21. 02 Jul, 2014 1 commit
  22. 03 Jun, 2014 1 commit
  23. 29 Apr, 2014 1 commit
  24. 25 Apr, 2014 3 commits