1. 05 Mar, 2019 1 commit
    • Sven Sauleau's avatar
      [wasm] correct Table limit · f4e322c3
      Sven Sauleau authored
      Align the Table implementation limits with the JavaScript Embedding
      limits defined in the specification (from MAX_UINT32 to 1e7).
      
      Introduce a new helper (max_table_init_entries) that returns the
      maximum number of Table entry at initialization. It takes into account
      the maximum Table size, which can be passed by a flag.
      
      Bug: v8:8633
      Change-Id: Idfa19418e81f478f7886a30876e66c9b216e25ac
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1496971
      Commit-Queue: Sven Sauleau <ssauleau@igalia.com>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60036}
      f4e322c3
  2. 30 Oct, 2018 1 commit
  3. 27 Jul, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Support 4GiB memories in Liftoff · 352e408b
      Ben L. Titzer authored
      Add codegen support for up to 4GiB memories in Liftoff code.
      
      This CL also adds three new mjsunit tests that stress large WASM
      memories (1, 2, and 4 GiB) and checks that accesses near these
      boundaries properly generate traps.
      
      Note there is still some trickiness around the setting of:
        1.) the flag --wasm-max-mem-pages
        2.) wasm-limits.h kSpecMaxWasmMemoryPages = 65536
        3.) wasm-limits.h kV8MaxWasmMemoryPages = 32767
      
      In particular, the allocation of memories is still limited to
      3.) and the runtime flag can only lower this limit.
      
      The above means that the tests for 2GiB and 4GiB memories will silently
      OOM by design until 3.) is changed (though they currently pass with
      manual testing). I argue it is better to include these tests up front,
      since they will immediately trigger if their memory allocation succeeds.
      
      Therefore the plan is to lift the restriction on 3.) after removing
      all other other internal V8 limitations including array buffers and views.
      
      R=clemensh@chromium.org
      CC=mstarzinger@chromium.org
      BUG=v8:7881
      
      Change-Id: I3205ac2daf5c9a84364c670a2c3ef2258e5649f6
      Reviewed-on: https://chromium-review.googlesource.com/1151309
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54754}
      352e408b
  4. 24 Jul, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Prepare to support 4GiB memories · dab10765
      Ben L. Titzer authored
      This is a preparatory CL that refactors the WASM memory allocation path,
      the WasmGraphBuilder, and several points of contact for ArrayBuffers to
      allow them to eventually be up to 4GiB.
      
      1.) Refactor definition of constants to prepare for memories of size 2^32
      2.) Refactor WasmInstanceObject fields memory_size and memory_mask to
          be stored as uintptr_t
      3.) Refactor WasmGraphBuilder to use 64-bit comparisons for bounds checks
      4.) Refactor JSArrayBuffer accessor methods to use size_t properly.
      5.) Add empirical maximum memory and array buffer size tests
      
      R=mstarzinger@chromium.org
      BUG=v8:7881
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: I78a49069cfa89757cc93f0a30b1c1a99c4b2edba
      Reviewed-on: https://chromium-review.googlesource.com/1112003
      Commit-Queue: Ben Titzer <titzer@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54646}
      dab10765
  5. 18 Jan, 2018 1 commit
  6. 11 Jan, 2018 1 commit
  7. 09 Jan, 2018 1 commit
  8. 05 Jan, 2018 1 commit
  9. 02 Nov, 2017 1 commit
    • Andreas Haas's avatar
      [wasm] Improve stack check in the interpreter · 793c52ed
      Andreas Haas authored
      The existing stack check only checked the number of stack frames on the
      stack, not the actual size of the stack frames. In the test case, each
      stack frame is huge, and the interpreter runs out of memory before the
      stack check stops the execution. With this change we take the size of
      the value stack and the size of the control stack and compare their sum
      to the stack limit of V8. Note that this stack limit is kind of
      arbitrary, because the stack space of the interpreter is not on the
      actual runtime stack but allocated in zone memory, and the stack check
      exists to simulate stack overflows in compiled code, not to prevent
      actual stack overflows.
      
      R=clemensh@chromium.org
      TEST=mjsunit/regress/wasm/regress-778917
      
      Bug: chromium:778917
      Change-Id: Ife47631fcb1a178a68facab1e42c0069b12c0155
      Reviewed-on: https://chromium-review.googlesource.com/744003
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49071}
      793c52ed
  10. 25 Oct, 2017 1 commit
  11. 10 Jul, 2017 1 commit
  12. 16 Jun, 2017 1 commit
  13. 14 Jun, 2017 2 commits
  14. 26 Apr, 2017 2 commits
    • Eric Holk's avatar
      Revert "[wasm] Add guard pages before Wasm Memory" · 54be464f
      Eric Holk authored
      This reverts commit d7cdea6f.
      
      Reason for revert: Flakiness on bots
      
      Original change's description:
      > [wasm] Add guard pages before Wasm Memory
      > 
      > Although Wasm memory indices are all unsigned, they sometimes get assembled
      > as 32-bit signed immediates. Values in the top half of the Wasm memory space
      > will then get sign extended, causing Wasm to access in front of its memory
      > buffer.
      > 
      > Usually this region is not mapped anyway, so faults still happen as they are
      > supposed to. This change protects this region with guard pages so we are
      > guaranteed to always fault when this happens.
      > 
      > Bug: v8:5277
      > Change-Id: Id791fbe2a5ac1b1d75460e65c72b5b9db2a47ee7
      > Reviewed-on: https://chromium-review.googlesource.com/484747
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#44905}
      
      TBR=bradnelson@chromium.org,gdeepti@chromium.org,mtrofin@chromium.org,eholk@chromium.org,mseaborn@chromium.org,adamk@chromium.org,v8-reviews@googlegroups.com,wasm-v8@google.com
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Change-Id: Ia1d3e5dbf4f518815a9fd4197047077bc8e42816
      Reviewed-on: https://chromium-review.googlesource.com/487828Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44907}
      54be464f
    • Eric Holk's avatar
      [wasm] Add guard pages before Wasm Memory · d7cdea6f
      Eric Holk authored
      Although Wasm memory indices are all unsigned, they sometimes get assembled
      as 32-bit signed immediates. Values in the top half of the Wasm memory space
      will then get sign extended, causing Wasm to access in front of its memory
      buffer.
      
      Usually this region is not mapped anyway, so faults still happen as they are
      supposed to. This change protects this region with guard pages so we are
      guaranteed to always fault when this happens.
      
      Bug: v8:5277
      Change-Id: Id791fbe2a5ac1b1d75460e65c72b5b9db2a47ee7
      Reviewed-on: https://chromium-review.googlesource.com/484747
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44905}
      d7cdea6f
  15. 31 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [wasm] [interpreter] Add stack overflow checks · 701124db
      Clemens Hammacher authored
      Add a limit to the number of nested call frames in the C++ wasm
      interpreter.
      Both the size of the value stack as well as the size of the block stack
      are limited per call frame. Thus, a limit on only the call frame stack
      is enough to limit the overall memory consumption of one interpreter
      instance.
      
      R=ahaas@chromium.org
      BUG=v8:5822
      
      Change-Id: If9f7e547cd1d003bc2ae3c7586ece6b3cf3be587
      Reviewed-on: https://chromium-review.googlesource.com/463486
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#44296}
      701124db
  16. 24 Jan, 2017 1 commit
  17. 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
  18. 17 Jan, 2017 1 commit
  19. 19 Dec, 2016 1 commit
  20. 14 Dec, 2016 1 commit
  21. 05 Dec, 2016 1 commit