Skip to content

V
V8
Switch branch/tag
  1. 20 May, 2022 2 commits
  3. 12 Apr, 2022 1 commit
  5. 13 Dec, 2021 1 commit
  7. 10 Dec, 2021 1 commit
  9. 16 Aug, 2021 1 commit
  11. 29 Jul, 2021 1 commit
  13. 14 Jun, 2021 1 commit
  15. 25 May, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up spec'ed max memory vs dynamic max · 2d04a627
      Clemens Backes authored 
      There are two different limits for the maximum memory size in
WebAssembly:
1) A 4GB limit which is the same on all platforms, and is observable for
JS programs. It is used to limit the allowed declared maximum size of a
wasm memory.
2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise)
which can be further limited using a command-line flag. This limit is
used whenever actually allocating or growing a wasm memory. This limit
is not directly observable, but we make sure that no wasm memory will
ever be bigger than this limit.

The second limit is the one we should check against when allocating or
growing memory, while the first limit should be used when validating
a module (or the parameters for WebAssembly.Memory). The compiler can
rely on no memory being bigger than the second limit, which again is
never bigger than the first limit.

This CL adds some more documentation to the two limits, and cleans up
all usages.
This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime}
obsolete.

R=jkummerow@chromium.org

Bug: chromium:1207263
Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74742}
      2d04a627
  17. 05 May, 2021 1 commit
  19. 13 Apr, 2021 1 commit
  21. 16 Mar, 2021 1 commit
  23. 16 Nov, 2020 1 commit
    • Jakob Kummerow's avatar
      [wasm-gc] Fix several bugs · 7e533de1
      Jakob Kummerow authored 
      - allow arrays to be allocated in LargeObjectSpace
- check requested array allocation length against maximum
- fix array element offsets for pointer-typed elements
- fix GC handling of arrays when there are forwarding pointers
- module builder: fix rtt.sub global initializer expressions
- debug printing: print "UNIMPLEMENTED" instead of crashing
- WasmGCTester: make some exceptions easier to diagnose

Bug: v8:7748, chromium:1141376
Change-Id: Ie0281658748f3dd5e5d90d85bab78f0ea2fc3865
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2534815Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71208}
      7e533de1
  25. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Remove --wasm-max-mem-pages-growth flag · 5f265c33
      Clemens Backes authored 
      This unifies {max_initial_mem_pages} and {max_maximum_mem_pages} into
{max_mem_pages}.
The {CompilationEnv} constructor was incorrectly using the former
instead of the latter anyway. This did not really matter though, since
they typically have the same value.
Also, there is not a single test that sets --wasm-max-mem-pages-growth.

R=manoskouk@chromium.org
CC=jkummerow@chromium.org

Bug: v8:10949
Change-Id: Ib7ab9b4c239d50b72013087eda5a214829c90369
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426619Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70114}
      5f265c33
  27. 11 Sep, 2020 1 commit
  29. 06 Aug, 2020 1 commit
    • Andreas Haas's avatar
      [wasm] Check size of tables dynamically · 47434265
      Andreas Haas authored 
      We used to check the size of tables at compile time, and threw a
CompilationError if a given size exceeded the implementation-defined
limit. However, the spec defines that an error should only be thrown
when the implementation-defined limit is reached, which is either at
instantiation time of during runtime at a table.grow.

With this CL the V8 implementation becomes spec compliant in this
regard.

R=jkummerow@chromium.org

Bug: v8:10556
Change-Id: I7d0e688b385a65e4060a569e5ab1dec68947ceea
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2326331
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69267}
      47434265
  31. 25 Jun, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Experimentally allow modules >1GB · 49097109
      Clemens Backes authored 
      Add an experimental flag to allow modules up to a size slightly below
2GB, to make sure that we don't run into integer overflows.
Modules this large are not tested at all currently, hence the explicit
"experimental" in the flag name.

Drive-by: Fix one comparison to use ">" instead of ">=".

R=ahaas@chromium.org
CC=​bmeurer@chromium.org

Bug: v8:10642
Change-Id: I91cfc290c262b9b81750e3c8af5358c1cd2572b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2266535Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68547}
      49097109
  33. 28 Feb, 2020 1 commit
  35. 24 Feb, 2020 1 commit
  37. 10 Jan, 2020 1 commit
  39. 24 Sep, 2019 1 commit
  41. 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
  43. 30 Oct, 2018 1 commit
  45. 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
  47. 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
  49. 18 Jan, 2018 1 commit
  51. 11 Jan, 2018 1 commit
  53. 09 Jan, 2018 1 commit
  55. 05 Jan, 2018 1 commit
  57. 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
  59. 25 Oct, 2017 1 commit
  61. 10 Jul, 2017 1 commit
  63. 16 Jun, 2017 1 commit
  65. 14 Jun, 2017 2 commits
  67. 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
  69. 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
  71. 24 Jan, 2017 1 commit
  73. 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