1. 29 Nov, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [wasm] Add more unit tests for trap handler · 3d2bc5d0
      Andreas Haas authored
      The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
      
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Patchset 1 is the original CL.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
      Reviewed-on: https://chromium-review.googlesource.com/c/1351024Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57947}
      3d2bc5d0
  2. 27 Nov, 2018 2 commits
    • Clemens Hammacher's avatar
      Revert "[wasm] Add more unit tests for trap handler" · 2fd07376
      Clemens Hammacher authored
      This reverts commit 4644b32e.
      
      Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
      
      Original change's description:
      > [wasm] Add more unit tests for trap handler
      > 
      > The unittests test if the trap handler only handles those traps it
      > is supposed to handle:
      > * Only handle traps when the thread-in-wasm flag is set.
      > * Only handle traps of the right type, i.e. memory access violations.
      > * Only handle traps at recorded instructions.
      > 
      > The tests also test the consistency of the thread-in-wasm flag. I made
      > one change in the trap handler where that consistency could be
      > violated.
      > 
      > All tests are executed with the default trap handler provided by V8,
      > and with the trap handler callback installed in a test signal/exception
      > handler.
      > 
      > Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      > Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      > Commit-Queue: Andreas Haas <ahaas@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#57858}
      
      TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
      
      Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/1351021Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57861}
      2fd07376
    • Andreas Haas's avatar
      [wasm] Add more unit tests for trap handler · 4644b32e
      Andreas Haas authored
      The unittests test if the trap handler only handles those traps it
      is supposed to handle:
      * Only handle traps when the thread-in-wasm flag is set.
      * Only handle traps of the right type, i.e. memory access violations.
      * Only handle traps at recorded instructions.
      
      The tests also test the consistency of the thread-in-wasm flag. I made
      one change in the trap handler where that consistency could be
      violated.
      
      All tests are executed with the default trap handler provided by V8,
      and with the trap handler callback installed in a test signal/exception
      handler.
      
      Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
      Reviewed-on: https://chromium-review.googlesource.com/c/1340246
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57858}
      4644b32e
  3. 19 Sep, 2018 3 commits
    • Clemens Hammacher's avatar
      Reland "[wasm] Introduce a soft limit on reserved memory" · 5e94b208
      Clemens Hammacher authored
      This is a reland of 3bb5cb63
      
      Original change's description:
      > [wasm] Introduce a soft limit on reserved memory
      > 
      > Currently, wasm memory and wasm code use a shared limit for the total
      > size of reservations. This can cause wasm code reservations to fail
      > because wasm memories used all available reservation space.
      > This CL introduces a soft limit which is used when allocating wasm
      > memory with full guards. If this limit is reached and the respective
      > flag is set, we fall back to allocation without full guards and check
      > against the hard limit. Code reservations always check against the hard
      > limit.
      > 
      > R=ahaas@chromium.org
      > 
      > Bug: v8:8196
      > Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d
      > Reviewed-on: https://chromium-review.googlesource.com/1233614
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56028}
      
      Bug: v8:8196
      Change-Id: If8baf429b02e23b344346f7335bc911b99ae5579
      Reviewed-on: https://chromium-review.googlesource.com/1233756Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56044}
      5e94b208
    • Leszek Swirski's avatar
      Revert "[wasm] Introduce a soft limit on reserved memory" · 196874aa
      Leszek Swirski authored
      This reverts commit 3bb5cb63.
      
      Reason for revert: Breaks Win64 bot https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/26418
      
      Original change's description:
      > [wasm] Introduce a soft limit on reserved memory
      > 
      > Currently, wasm memory and wasm code use a shared limit for the total
      > size of reservations. This can cause wasm code reservations to fail
      > because wasm memories used all available reservation space.
      > This CL introduces a soft limit which is used when allocating wasm
      > memory with full guards. If this limit is reached and the respective
      > flag is set, we fall back to allocation without full guards and check
      > against the hard limit. Code reservations always check against the hard
      > limit.
      > 
      > R=​ahaas@chromium.org
      > 
      > Bug: v8:8196
      > Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d
      > Reviewed-on: https://chromium-review.googlesource.com/1233614
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#56028}
      
      TBR=ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: If645e738b4a5800eceabd993738ac2285f4a63bc
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8196
      Reviewed-on: https://chromium-review.googlesource.com/1233834Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56031}
      196874aa
    • Clemens Hammacher's avatar
      [wasm] Introduce a soft limit on reserved memory · 3bb5cb63
      Clemens Hammacher authored
      Currently, wasm memory and wasm code use a shared limit for the total
      size of reservations. This can cause wasm code reservations to fail
      because wasm memories used all available reservation space.
      This CL introduces a soft limit which is used when allocating wasm
      memory with full guards. If this limit is reached and the respective
      flag is set, we fall back to allocation without full guards and check
      against the hard limit. Code reservations always check against the hard
      limit.
      
      R=ahaas@chromium.org
      
      Bug: v8:8196
      Change-Id: I3fcbaeaa6f72c972d408d291af5d6b788d43151d
      Reviewed-on: https://chromium-review.googlesource.com/1233614Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#56028}
      3bb5cb63
  4. 18 Sep, 2018 1 commit
  5. 13 Sep, 2018 1 commit
  6. 17 Aug, 2018 1 commit
  7. 18 Jul, 2018 1 commit
  8. 05 Jul, 2018 1 commit
  9. 07 Jun, 2018 1 commit
    • Eric Holk's avatar
      [wasm] Fall back on bounds checks when guarded memory unavailable · b984b70c
      Eric Holk authored
      This CL adds the simplest version of a trap handler fallback. At
      instantiation time, we check whether the module was compiled to use
      trap handlers and the memory is guarded. If the memory is not guarded
      but the module is supposed to use trap handlers, we recompile the
      module with bounds checks so that we can use an unguarded memory.
      
      The compiled module is replaced with a bounds checking version, meaning
      future instances from this module will also use bounds checks.
      
      Some likely desirable features that are current missing but can be
      added future CLs include:
      * Disabling trap handler mode entirely.
      * Recompiling all old instances so that trap handler and bounds checked
        code does not coexist in the same process.
      
      Bug: v8:7143
      
      Change-Id: I161fc0d544133b07dc4a93cc6af813369aaf3efe
      Reviewed-on: https://chromium-review.googlesource.com/1018182
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#53566}
      b984b70c
  10. 29 May, 2018 1 commit
  11. 02 May, 2018 1 commit
  12. 30 Apr, 2018 1 commit
  13. 24 Apr, 2018 1 commit
    • Eric Holk's avatar
      [wasm] Add metrics for Wasm memory allocation · 45dd38c1
      Eric Holk authored
      This adds two new UMA histograms to give us more insight into Wasm
      memory allocation.
      
      The first records the result of every attempt to to allocate a Wasm
      backing store. This will let us know things like how often we
      explicitly trigger a GC, or how often we hit our address space limit.
      
      The second records how many megabytes of address space Wasm reserves.
      A sample is added every time the number either increases or decreases.
      This metric will give us a sense of how many outstanding Wasm memories
      there are in typical usage.
      
      Change-Id: I38c1bc1ad915c26b6cda3c373ededdd395193a4c
      Reviewed-on: https://chromium-review.googlesource.com/1024646
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52767}
      45dd38c1
  14. 06 Apr, 2018 1 commit
  15. 05 Apr, 2018 1 commit
  16. 04 Apr, 2018 1 commit
  17. 03 Apr, 2018 1 commit
    • Eric Holk's avatar
      Revert "[wasm] Always enable guard regions on 64-bit platforms" · 76e79f0f
      Eric Holk authored
      This reverts commit 0cd7468b.
      
      Reason for revert: Blocks v8 roll into chromium: https://crbug.com/828499
      
      Original change's description:
      > [wasm] Always enable guard regions on 64-bit platforms
      > 
      > This change makes full 8 GiB guard regions always enabled on 64-bit
      > platforms.
      > 
      > Additionally, since all Wasm memory allocation paths have some form of
      > guard regions, this removes and simplifies most of the logic around
      > whether to enable guard regions.
      > 
      > R=​gdeepti@chromium.org
      > 
      > Change-Id: Idf3fbcc11ac70ea2ee7eb88c2173d6a1410395e1
      > Reviewed-on: https://chromium-review.googlesource.com/985142
      > Commit-Queue: Eric Holk <eholk@chromium.org>
      > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52310}
      
      TBR=bradnelson@chromium.org,gdeepti@chromium.org,eholk@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Change-Id: I126b5afe283a4fe08adfa301e637d2641c29cccd
      Reviewed-on: https://chromium-review.googlesource.com/993160Reviewed-by: 's avatarEric Holk <eholk@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52334}
      76e79f0f
  18. 30 Mar, 2018 1 commit
  19. 29 Mar, 2018 1 commit
  20. 22 Mar, 2018 1 commit
    • Eric Holk's avatar
      [wasm] always allocate memory when guard regions are needed · d31dff84
      Eric Holk authored
      When using trap handlers, memory references do not get any checks inserted. This
      means there is no check for a null memory as happens when the memory size is
      0. Normally this would be correctly caught as an out of bounds access, since the
      low memory addresses are not normally mapped. However, if they were mapped for
      some reason, we would not catch the out of bounds access.
      
      The fix is to ensure WebAssembly instances always have a guard region even if
      the memory is size 0.
      
      This is a rewrite of 5e76ff5a
      
      Note that this can lead to a large amount of unnecessary address space usage,
      so we share a single reservation for empty array buffers.
      
      Bug: chromium:769637
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: Ia8e84be6d595e347d3d342959f2c374db1a3f683
      Reviewed-on: https://chromium-review.googlesource.com/702657Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52163}
      d31dff84
  21. 20 Mar, 2018 1 commit
  22. 02 Feb, 2018 1 commit
  23. 16 Jan, 2018 1 commit
  24. 08 Jan, 2018 1 commit
  25. 06 Jan, 2018 1 commit
  26. 05 Jan, 2018 1 commit
  27. 21 Dec, 2017 1 commit
  28. 17 Oct, 2017 1 commit
  29. 10 Oct, 2017 1 commit
    • Eric Holk's avatar
      [wasm] Remove --wasm-guard-pages flag · 69d790e5
      Eric Holk authored
      This flag was originally added as a staging mechanism to let us land and test
      guard regions without the full trap handler feature landing. Additionally, we
      thought we might enable guard regions without trap handlers on some systems.
      
      Trap handlers are now supported, and there's not a real compelling reason for
      why we need guard regions without trap handlers. Keeping the separate flag leads
      to confusion, since some code treats guard regions and trap handlers the same,
      while other code treats them as independent.
      
      Removing this flag and its associated special cases makes everything more
      uniform and predictable.
      
      R=gdeepti@chromium.org
      
      Change-Id: Icebab91d1f1e0c55e7a35c75b880085d37fa14ae
      Reviewed-on: https://chromium-review.googlesource.com/706570Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarMircea Trofin <mtrofin@chromium.org>
      Commit-Queue: Eric Holk <eholk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48411}
      69d790e5
  30. 02 Oct, 2017 1 commit