|
|
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-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}
Committed: https://chromium.googlesource.com/v8/v8/+/1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6
Patch Set 1 #Patch Set 2 : Fix test to include -1 as a valid result #Patch Set 3 : Remove check that crashed on wrap around #Patch Set 4 : Add check back #Patch Set 5 : Fix cast #Patch Set 6 : Split, skip test on 32-bit simulators #Patch Set 7 : Fix status file #Patch Set 8 : Fix status again #
Total comments: 17
Patch Set 9 : Eric's review #
Total comments: 4
Patch Set 10 : Brad's review #Patch Set 11 : Remove incorrect DCHECK #
Messages
Total messages: 76 (63 generated)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_arm_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng_trigger...)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_arm_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng_trigger...)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_arm_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng_trigger...)
The CQ bit was checked by gdeepti@chromium.org
The CQ bit was unchecked by gdeepti@chromium.org
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_arm_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng_trigger...)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_nosnap_shared_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...) v8_win_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/29030)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Patchset #5 (id:80001) has been deleted
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux_arm_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng/builds/...) v8_linux_arm_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_arm_rel_ng_trigger...)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...) v8_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...) v8_linux_verify_csa_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_verify_csa_rel_ng/...) v8_linux_verify_csa_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_verify_csa_rel_ng_...)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_avx2_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng/buil...) v8_linux64_avx2_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel_ng_trig...) v8_linux64_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/27367) v8_linux64_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng_triggered...) v8_linux_nodcheck_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng/bu...) v8_linux_nodcheck_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_nodcheck_rel_ng_tr...) v8_linux_verify_csa_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_verify_csa_rel_ng/...) v8_linux_verify_csa_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_verify_csa_rel_ng_...)
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== Increase V8MaxWasmMemoryPages to ~2gb BUG= ========== to ========== [wasm] Increase WebAssembly.Memory maximum size to 2GB BUG=v8:6478 R=bradnelson@chromium.org, eholk@chromium.org ==========
gdeepti@chromium.org changed reviewers: + bradnelson@chromium.org, eholk@chromium.org
Description was changed from ========== [wasm] Increase WebAssembly.Memory maximum size to 2GB BUG=v8:6478 R=bradnelson@chromium.org, eholk@chromium.org ========== to ========== [wasm] Increase WebAssembly.Memory maximum size to 2GB BUG=v8:6478, chromium:729768 R=bradnelson@chromium.org, eholk@chromium.org ==========
https://codereview.chromium.org/2903153002/diff/160001/src/wasm/wasm-limits.h File src/wasm/wasm-limits.h (right): https://codereview.chromium.org/2903153002/diff/160001/src/wasm/wasm-limits.h... src/wasm/wasm-limits.h:25: constexpr size_t kV8MaxWasmMemoryPages = 32767; // ~ 2 GiB Nit: Isn't this exactly 2 GiB, not just ~ 2 GiB? https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... File test/mjsunit/mjsunit.status (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... test/mjsunit/mjsunit.status:342: ['arch == arm and simulator_run == True or arch == ppc and simulator_run == True', { Should these be wrapped to 80 chararacters? https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... test/mjsunit/mjsunit.status:345: # on 32 bit arch simulators I'm not sure I understand this. Just to make sure, we're talking about running the simulator on a 64-bit host, right? Otherwise everything is in the lower 4gb address space. I'm surprised the simulator can assume the memory is in the lower 4GB space. Can't the OS put the allocation anywhere? https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/grow... File test/mjsunit/wasm/grow-memory.js (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/grow... test/mjsunit/wasm/grow-memory.js:496: print("testGrowMemory2Gb"); Thanks for printing the test name! This makes it a lot easier to debug when we need to. https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/grow... test/mjsunit/wasm/grow-memory.js:525: assertTraps(kTrapMemOutOfBounds, poke); I think it'd be good to test a couple of addresses in the 3GB to 4GB range, since this is where we can run into sign extension problems. It looks like this test gets up to 2GB + 4 bytes, but going further out of bounds would be useful. There might be other tests that cover this range, although I wonder if high addresses with a large memory size might lead to different problems. https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/impo... File test/mjsunit/wasm/import-memory.js (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/impo... test/mjsunit/wasm/import-memory.js:179: assertThrows(() => memory.grow(32765)); Maybe add a comment for why this number was chosen? https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/larg... File test/mjsunit/wasm/large-offset.js (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/larg... test/mjsunit/wasm/large-offset.js:17: kExprI32StoreMem, 0, 0xFF, 0xFF, 0xFF, 0x7a Ah, here's the way out of bounds test! Thanks. Could you add a comment with what 0xFF, 0xFF, 0xFF, 0x7a decodes to?
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2903153002/diff/160001/src/wasm/wasm-limits.h File src/wasm/wasm-limits.h (right): https://codereview.chromium.org/2903153002/diff/160001/src/wasm/wasm-limits.h... src/wasm/wasm-limits.h:25: constexpr size_t kV8MaxWasmMemoryPages = 32767; // ~ 2 GiB On 2017/06/13 16:19:47, Eric Holk wrote: > Nit: Isn't this exactly 2 GiB, not just ~ 2 GiB 32768 is exactly 2GiB, this is one page less. https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... File test/mjsunit/mjsunit.status (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... test/mjsunit/mjsunit.status:342: ['arch == arm and simulator_run == True or arch == ppc and simulator_run == True', { On 2017/06/13 16:19:47, Eric Holk wrote: > Should these be wrapped to 80 chararacters? I don't know if there's a way to wrap around in status files, this is consistent with the way long conditionals are handled in the rest of the file. https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... test/mjsunit/mjsunit.status:345: # on 32 bit arch simulators On 2017/06/13 16:19:47, Eric Holk wrote: > I'm not sure I understand this. Just to make sure, we're talking about running > the simulator on a 64-bit host, right? Otherwise everything is in the lower 4gb > address space. I'm surprised the simulator can assume the memory is in the lower > 4GB space. Can't the OS put the allocation anywhere? My comment is not indicative of what is actually happening (fixed comment) - some more context for what is happening here: The right phrasing is that the allocator assumes address space to be in the signed int32 range, because of this when using a large offset the computation exceeds a signed 32-bit type, the addresses wrap around and hit DCHECKS which work as expected on hardware. As per my understanding ARM, PPC simulators are run on 32 bit hosts for the respective target architecture, and ARM64 etc. on 64 bit hosts. See test that fails here - causing this computation to exceed a signed 32-bit type https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/grow... File test/mjsunit/wasm/grow-memory.js (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/grow... test/mjsunit/wasm/grow-memory.js:496: print("testGrowMemory2Gb"); On 2017/06/13 16:19:48, Eric Holk wrote: > Thanks for printing the test name! This makes it a lot easier to debug when we > need to. I agree it makes easier debugging. :) I have an AI to retroactively refactor this file/print names for tests . https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/grow... test/mjsunit/wasm/grow-memory.js:525: assertTraps(kTrapMemOutOfBounds, poke); On 2017/06/13 16:19:48, Eric Holk wrote: > I think it'd be good to test a couple of addresses in the 3GB to 4GB range, > since this is where we can run into sign extension problems. It looks like this > test gets up to 2GB + 4 bytes, but going further out of bounds would be useful. > > There might be other tests that cover this range, although I wonder if high > addresses with a large memory size might lead to different problems. Done. https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/impo... File test/mjsunit/wasm/import-memory.js (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/impo... test/mjsunit/wasm/import-memory.js:179: assertThrows(() => memory.grow(32765)); On 2017/06/13 16:19:48, Eric Holk wrote: > Maybe add a comment for why this number was chosen? Used max memory limits here instead, and fine tuned the number so it should make more sense now. https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/larg... File test/mjsunit/wasm/large-offset.js (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/wasm/larg... test/mjsunit/wasm/large-offset.js:17: kExprI32StoreMem, 0, 0xFF, 0xFF, 0xFF, 0x7a On 2017/06/13 16:19:48, Eric Holk wrote: > Ah, here's the way out of bounds test! Thanks. > > Could you add a comment with what 0xFF, 0xFF, 0xFF, 0x7a decodes to? Done.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
lgtm, but I don't have OWNERS. https://codereview.chromium.org/2903153002/diff/160001/src/wasm/wasm-limits.h File src/wasm/wasm-limits.h (right): https://codereview.chromium.org/2903153002/diff/160001/src/wasm/wasm-limits.h... src/wasm/wasm-limits.h:25: constexpr size_t kV8MaxWasmMemoryPages = 32767; // ~ 2 GiB On 2017/06/13 21:25:43, gdeepti wrote: > On 2017/06/13 16:19:47, Eric Holk wrote: > > Nit: Isn't this exactly 2 GiB, not just ~ 2 GiB > > 32768 is exactly 2GiB, this is one page less. Acknowledged. https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... File test/mjsunit/mjsunit.status (right): https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... test/mjsunit/mjsunit.status:342: ['arch == arm and simulator_run == True or arch == ppc and simulator_run == True', { On 2017/06/13 21:25:43, gdeepti wrote: > On 2017/06/13 16:19:47, Eric Holk wrote: > > Should these be wrapped to 80 chararacters? > > I don't know if there's a way to wrap around in status files, this is consistent > with the way long conditionals are handled in the rest of the file. sgtm https://codereview.chromium.org/2903153002/diff/160001/test/mjsunit/mjsunit.s... test/mjsunit/mjsunit.status:345: # on 32 bit arch simulators On 2017/06/13 21:25:43, gdeepti wrote: > On 2017/06/13 16:19:47, Eric Holk wrote: > > I'm not sure I understand this. Just to make sure, we're talking about running > > the simulator on a 64-bit host, right? Otherwise everything is in the lower > 4gb > > address space. I'm surprised the simulator can assume the memory is in the > lower > > 4GB space. Can't the OS put the allocation anywhere? > > My comment is not indicative of what is actually happening (fixed comment) - > some more context for what is happening here: The right phrasing is that the > allocator assumes address space to be in the signed int32 range, because of this > when using a large offset the computation exceeds a signed 32-bit type, the > addresses wrap around and hit DCHECKS which work as expected on hardware. As per > my understanding ARM, PPC simulators are run on 32 bit hosts for the respective > target architecture, and ARM64 etc. on 64 bit hosts. > > See test that fails here - causing this computation to exceed a signed 32-bit > type > sgtm https://codereview.chromium.org/2903153002/diff/180001/test/mjsunit/wasm/impo... File test/mjsunit/wasm/import-memory.js (right): https://codereview.chromium.org/2903153002/diff/180001/test/mjsunit/wasm/impo... test/mjsunit/wasm/import-memory.js:180: assertThrows(() => memory.grow(kV8MaxPages - 3)); So the -3 is because the previous for loop grew by one page four times and we want to grow to one page beyond the limit, right?
Ping bradnelson@ for OWNERS review. https://codereview.chromium.org/2903153002/diff/180001/test/mjsunit/wasm/impo... File test/mjsunit/wasm/import-memory.js (right): https://codereview.chromium.org/2903153002/diff/180001/test/mjsunit/wasm/impo... test/mjsunit/wasm/import-memory.js:180: assertThrows(() => memory.grow(kV8MaxPages - 3)); On 2017/06/13 22:37:20, Eric Holk wrote: > So the -3 is because the previous for loop grew by one page four times and we > want to grow to one page beyond the limit, right? Yep, that's right.
lgtm https://codereview.chromium.org/2903153002/diff/180001/src/wasm/wasm-limits.h File src/wasm/wasm-limits.h (right): https://codereview.chromium.org/2903153002/diff/180001/src/wasm/wasm-limits.h... src/wasm/wasm-limits.h:25: constexpr size_t kV8MaxWasmMemoryPages = 32767; // ~ 2 GiB Explain why not all the way up.
https://codereview.chromium.org/2903153002/diff/180001/src/wasm/wasm-limits.h File src/wasm/wasm-limits.h (right): https://codereview.chromium.org/2903153002/diff/180001/src/wasm/wasm-limits.h... src/wasm/wasm-limits.h:25: constexpr size_t kV8MaxWasmMemoryPages = 32767; // ~ 2 GiB On 2017/06/13 23:34:23, bradnelson wrote: > Explain why not all the way up. Done.
The CQ bit was checked by gdeepti@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from eholk@chromium.org, bradnelson@chromium.org Link to the patchset: https://codereview.chromium.org/2903153002/#ps200001 (title: "Brad's review")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 200001, "attempt_start_ts": 1497400102335330, "parent_rev": "284a4804f2f2cab172d2b4d96048b5d8986c72cd", "commit_rev": "7e6ed62071d2756688a23bd6dac096b0d4660b5d"}
Message was sent while issue was closed.
Description was changed from ========== [wasm] Increase WebAssembly.Memory maximum size to 2GB BUG=v8:6478, chromium:729768 R=bradnelson@chromium.org, eholk@chromium.org ========== to ========== [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/+/7e6ed62071d2756688a23bd6dac096b0d46... ==========
Message was sent while issue was closed.
Committed patchset #10 (id:200001) as https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d46...
Message was sent while issue was closed.
A revert of this CL (patchset #10 id:200001) has been created in https://codereview.chromium.org/2935243002/ by machenbach@chromium.org. The reason for reverting is: gc stress failure: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/....
Message was sent while issue was closed.
Description was changed from ========== [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/+/7e6ed62071d2756688a23bd6dac096b0d46... ========== to ========== [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/+/7e6ed62071d2756688a23bd6dac096b0d46... ==========
The CQ bit was checked by gdeepti@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
The CQ bit was checked by gdeepti@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from eholk@chromium.org, bradnelson@chromium.org Link to the patchset: https://codereview.chromium.org/2903153002/#ps220001 (title: "Remove incorrect DCHECK")
On 2017/06/14 06:39:31, machenbach (OOO) wrote: > A revert of this CL (patchset #10 id:200001) has been created in > https://codereview.chromium.org/2935243002/ by mailto:machenbach@chromium.org. > > The reason for reverting is: gc stress failure: > https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/.... Relanding after removing incorrect DCHECK.
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 220001, "attempt_start_ts": 1497583995354270, "parent_rev": "431abca0caed834fc23fe146c98eee46efa9d0e9", "commit_rev": "1ff3e7ea3352e3ee4baf8851cfe80129cc5fa8e6"}
Message was sent while issue was closed.
Description was changed from ========== [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/+/7e6ed62071d2756688a23bd6dac096b0d46... ========== to ========== [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-Original-Commit-Position: refs/heads/master@{#45931} Committed: https://chromium.googlesource.com/v8/v8/+/7e6ed62071d2756688a23bd6dac096b0d46... Review-Url: https://codereview.chromium.org/2903153002 Cr-Commit-Position: refs/heads/master@{#45967} Committed: https://chromium.googlesource.com/v8/v8/+/1ff3e7ea3352e3ee4baf8851cfe80129cc5... ==========
Message was sent while issue was closed.
Committed patchset #11 (id:220001) as https://chromium.googlesource.com/v8/v8/+/1ff3e7ea3352e3ee4baf8851cfe80129cc5... |