- 05 Mar, 2019 1 commit
-
-
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: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#60036}
-
- 30 Oct, 2018 1 commit
-
-
Clemens Hammacher authored
For memory limit checks, we should use the minimum of the --wasm-max-mem-pages flag and kV8MaxWasmMemoryPages. The former is a limit set by the user, the latter is the maximum we can handle internally. R=titzer@chromium.org Bug: chromium:898677 Change-Id: I3c549f4e90dd016b5d07475d9353f30134f76dcc Reviewed-on: https://chromium-review.googlesource.com/c/1305274 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#57127}
-
- 27 Jul, 2018 1 commit
-
-
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: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#54754}
-
- 24 Jul, 2018 1 commit
-
-
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: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#54646}
-
- 18 Jan, 2018 1 commit
-
-
Clemens Hammacher authored
This prepares a reland of https://crrev.com/c/869468. Drive-by: Add a static_assert, also to document why kV8MaxWasmMemoryPages was chosed to be slightly below 2GB. R=titzer@chromium.org CC=bradnelson@chromium.org Bug: v8:6600 Change-Id: I6417bec191803c791fa5b218024ebcfde27e2aea Reviewed-on: https://chromium-review.googlesource.com/873912Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#50692}
-
- 11 Jan, 2018 1 commit
-
-
Ben L. Titzer authored
This CL centralizes constants related to decoding from several places into one place and makes it no longer necessary to include wasm-opcodes.h for some simple constants. R=clemensh@chromium.org Bug: Change-Id: I53aa81e34167df467bc7455b717bf67083033943 Reviewed-on: https://chromium-review.googlesource.com/859764 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#50503}
-
- 09 Jan, 2018 1 commit
-
-
Ben L. Titzer authored
Combined with existing masking, provides protection against speculative OOB accesses. R=clemensh@chromium.org Bug: chromium:798964 Change-Id: Ib7cdc8bccc6d22b8b45896c63f69cb647deba383 Reviewed-on: https://chromium-review.googlesource.com/856980 Commit-Queue: Ben Titzer <titzer@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#50448}
-
- 05 Jan, 2018 1 commit
-
-
Clemens Hammacher authored
Even though kSpecMaxWasmMemoryPages == WasmModule::kPageSize, the computation {wasm::kV8MaxWasmMemoryPages * wasm::kSpecMaxWasmMemoryPages} is semantically wrong. R=titzer@chromium.org Change-Id: If4a875c714f1ca3c1fc928ec79b8be8aab62e8d0 Reviewed-on: https://chromium-review.googlesource.com/850072Reviewed-by: Ben Titzer <titzer@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#50375}
-
- 02 Nov, 2017 1 commit
-
-
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: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#49071}
-
- 25 Oct, 2017 1 commit
-
-
Ben L. Titzer authored
Pending the outcome of the discussion on the GitHub issue: https://github.com/WebAssembly/design/issues/1138 R=clemensh@chromium.org,ahaas@chromium.org Bug: Change-Id: I54a218a93c24cb221b9f0195e2b1abbe6208d8e2 Reviewed-on: https://chromium-review.googlesource.com/735343Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48907}
-
- 10 Jul, 2017 1 commit
-
-
Karl Schimpf authored
Modifies V8 to be able to parse the exception section (defining exception types), when the experimental_wasm_eh flag is true. Bug: v8:6577 Change-Id: I5d8b3fddaf5b0dec6b14ddd0992f9fb883e8dc90 Reviewed-on: https://chromium-review.googlesource.com/561757 Commit-Queue: Karl Schimpf <kschimpf@chromium.org> Reviewed-by: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#46539}
-
- 16 Jun, 2017 1 commit
-
-
gdeepti authored
BUG=v8:6478, chromium:729768 R=bradnelson@chromium.org, eholk@chromium.org Review-Url: https://codereview.chromium.org/2903153002 Cr-Original-Commit-Position: refs/heads/master@{#45931} Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d4660b5d Review-Url: https://codereview.chromium.org/2903153002 Cr-Commit-Position: refs/heads/master@{#45967}
-
- 14 Jun, 2017 2 commits
-
-
machenbach authored
Revert of [wasm] Increase WebAssembly.Memory maximum size to ~2GB (patchset #10 id:200001 of https://codereview.chromium.org/2903153002/ ) Reason for revert: gc stress failure: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/11122 Original issue's description: > [wasm] Increase WebAssembly.Memory maximum size to 2GB > > BUG=v8:6478, chromium:729768 > > R=bradnelson@chromium.org, eholk@chromium.org > > Review-Url: https://codereview.chromium.org/2903153002 > Cr-Commit-Position: refs/heads/master@{#45931} > Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d4660b5d TBR=bradnelson@chromium.org,eholk@chromium.org,gdeepti@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:6478, chromium:729768 Review-Url: https://codereview.chromium.org/2935243002 Cr-Commit-Position: refs/heads/master@{#45932}
-
gdeepti authored
BUG=v8:6478, chromium:729768 R=bradnelson@chromium.org, eholk@chromium.org Review-Url: https://codereview.chromium.org/2903153002 Cr-Commit-Position: refs/heads/master@{#45931}
-
- 26 Apr, 2017 2 commits
-
-
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: Adam Klein <adamk@chromium.org> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#44907}
-
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: Mircea Trofin <mtrofin@chromium.org> Cr-Commit-Position: refs/heads/master@{#44905}
-
- 31 Mar, 2017 1 commit
-
-
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: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#44296}
-
- 24 Jan, 2017 1 commit
-
-
ahaas authored
Similar to the maximum memory size this limit caused problems for the fuzzer due to oom issues. With the command line flag we can limit the maximum table size for the fuzzer. R=titzer@chromium.org Review-Url: https://codereview.chromium.org/2648223004 Cr-Commit-Position: refs/heads/master@{#42623}
-
- 23 Jan, 2017 1 commit
-
-
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}
-
- 17 Jan, 2017 1 commit
-
-
titzer authored
R=rossberg@chromium.org BUG=chromium:575167 Review-Url: https://codereview.chromium.org/2636173002 Cr-Commit-Position: refs/heads/master@{#42426}
-
- 19 Dec, 2016 1 commit
-
-
titzer authored
R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2587003002 Cr-Commit-Position: refs/heads/master@{#41808}
-
- 14 Dec, 2016 1 commit
-
-
titzer authored
This CL moves even more limits to wasm-limits.h and enforces limits for types, functions, parameter counts, return counts, local counts, imports, globals, and exports. R=clemensh@chromium.org, ahaas@chromium.org BUG= Review-Url: https://codereview.chromium.org/2574133002 Cr-Commit-Position: refs/heads/master@{#41699}
-
- 05 Dec, 2016 1 commit
-
-
titzer authored
R=clemensh@chromium.org BUG= Review-Url: https://codereview.chromium.org/2551463002 Cr-Commit-Position: refs/heads/master@{#41477}
-