Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2520963002:
[d8] Use virtual memory to allocate large array buffers. (Closed)
Description[d8] Use virtual memory to allocate large array buffers.
R=mstarzinger@chromium.org,clemensh@chromium.org
BUG=
Committed: https://crrev.com/d96131ed9bf14bd7ec13bbf19c2c6caebf851a14
Cr-Commit-Position: refs/heads/master@{#41154}
Patch Set 1 #
Total comments: 4
Patch Set 2 : Add MSAN hook #Patch Set 3 : Update comment. #Patch Set 4 : [d8] Use virtual memory to allocate large array buffers. #
Total comments: 1
Patch Set 5 : [d8] Use virtual memory to allocate large array buffers. #Patch Set 6 : [d8] Use virtual memory to allocate large array buffers. #Patch Set 7 : [d8] Use virtual memory to allocate large array buffers. #Patch Set 8 : Fail for >= 2gb #Messages
Total messages: 35 (22 generated)
The CQ bit was checked by titzer@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...
mstarzinger@chromium.org changed reviewers: + mlippautz@chromium.org
LGTM from my end, but I am not deeply familiar with the contract of
{VirtualMemory}. Adding Mike for an additional pair of eyes.
https://codereview.chromium.org/2520963002/diff/1/src/d8.cc
File src/d8.cc (right):
https://codereview.chromium.org/2520963002/diff/1/src/d8.cc#newcode74
src/d8.cc:74: if (data && !base::VirtualMemory::CommitRegion(data, length,
false)) {
This relies on the mamory being provided by the underlying platform
implementation of {VirtualMemory} being zero-initialized. I don't think we rely
on this anywhere else in V8. Does this hold on all platforms?
Also is ASAN fine with not explicitly initializing the memory first? I see a
try-bot for ASAN in the CQ and it seems to be green. So assume that this path is
covered on that bot?
https://codereview.chromium.org/2520963002/diff/1/src/d8.cc File src/d8.cc (right): https://codereview.chromium.org/2520963002/diff/1/src/d8.cc#newcode74 src/d8.cc:74: if (data && !base::VirtualMemory::CommitRegion(data, length, false)) { On 2016/11/21 13:58:09, Michael Starzinger wrote: > This relies on the mamory being provided by the underlying platform > implementation of {VirtualMemory} being zero-initialized. I don't think we rely > on this anywhere else in V8. Does this hold on all platforms? > > Also is ASAN fine with not explicitly initializing the memory first? I see a > try-bot for ASAN in the CQ and it seems to be green. So assume that this path is > covered on that bot? Same for the other *SANs, not sure which one it is. :)
clemensh@chromium.org changed reviewers: - mlippautz@chromium.org
What happens in OOM situation on lazily allocated pages? OOM killer, no SEGV, right? Otherwise this might interfere with the trap handler stuff. https://codereview.chromium.org/2520963002/diff/1/src/d8.cc File src/d8.cc (right): https://codereview.chromium.org/2520963002/diff/1/src/d8.cc#newcode80 src/d8.cc:80: #endif The code duplication bothers me. We call AllocateUninitialized anyway, so can't we just skip the memset if RoundToPageSize(&length)? https://codereview.chromium.org/2520963002/diff/1/src/d8.cc#newcode106 src/d8.cc:106: // If {length} is at least a page, round up to next page size and return ... at least VM_THRESHOLD, ...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Description was changed from ========== [d8] Use virtual memory to allocate large array buffers. R=mstarzinger@chromium.org,clemensh@chromium.org BUG= ========== to ========== [d8] Use virtual memory to allocate large array buffers. R=mstarzinger@chromium.org,clemensh@chromium.org BUG= ==========
mstarzinger@chromium.org changed reviewers: + mlippautz@chromium.org
The CQ bit was checked by titzer@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...
On 2016/11/21 13:58:09, Michael Starzinger wrote:
> LGTM from my end, but I am not deeply familiar with the contract of
> {VirtualMemory}. Adding Mike for an additional pair of eyes.
>
> https://codereview.chromium.org/2520963002/diff/1/src/d8.cc
> File src/d8.cc (right):
>
> https://codereview.chromium.org/2520963002/diff/1/src/d8.cc#newcode74
> src/d8.cc:74: if (data && !base::VirtualMemory::CommitRegion(data, length,
> false)) {
> This relies on the mamory being provided by the underlying platform
> implementation of {VirtualMemory} being zero-initialized. I don't think we
rely
> on this anywhere else in V8. Does this hold on all platforms?
>
I've added an explicit check in debug mode.
> Also is ASAN fine with not explicitly initializing the memory first? I see a
> try-bot for ASAN in the CQ and it seems to be green. So assume that this path
is
> covered on that bot?
Added MSAN notifications here.
On 2016/11/21 14:00:28, Clemens Hammacher wrote: > What happens in OOM situation on lazily allocated pages? OOM killer, no SEGV, > right? Otherwise this might interfere with the trap handler stuff. > No SEGV, correct. Note that we do commit the reservation, but that is only mild assurance against the kernel oversubscribing the VMM. > https://codereview.chromium.org/2520963002/diff/1/src/d8.cc > File src/d8.cc (right): > > https://codereview.chromium.org/2520963002/diff/1/src/d8.cc#newcode80 > src/d8.cc:80: #endif > The code duplication bothers me. We call AllocateUninitialized anyway, so can't > we just skip the memset if RoundToPageSize(&length)? > I've factored out a common routine. > https://codereview.chromium.org/2520963002/diff/1/src/d8.cc#newcode106 > src/d8.cc:106: // If {length} is at least a page, round up to next page size and > return > ... at least VM_THRESHOLD, ... Done.
lgtm, very cool patch! https://codereview.chromium.org/2520963002/diff/60001/src/d8.cc File src/d8.cc (right): https://codereview.chromium.org/2520963002/diff/60001/src/d8.cc#newcode103 src/d8.cc:103: // If {length} is at least a {VM_THRESHOLD}, round up to next page size Nit: still an "a" to much ;)
On 2016/11/21 15:49:24, Clemens Hammacher wrote: > lgtm, very cool patch! > > https://codereview.chromium.org/2520963002/diff/60001/src/d8.cc > File src/d8.cc (right): > > https://codereview.chromium.org/2520963002/diff/60001/src/d8.cc#newcode103 > src/d8.cc:103: // If {length} is at least a {VM_THRESHOLD}, round up to next > page size > Nit: still an "a" to much ;) Done. Thanks.
The CQ bit was checked by titzer@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from mstarzinger@chromium.org, clemensh@chromium.org Link to the patchset: https://codereview.chromium.org/2520963002/#ps80001 (title: "[d8] Use virtual memory to allocate large array buffers.")
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
Try jobs failed on following builders: v8_linux_dbg_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng/builds/16611) v8_linux_dbg_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_dbg_ng_triggered/b...)
The CQ bit was checked by titzer@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_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_rel_ng/builds/16574) 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_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng/builds/16533) v8_linux_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux_rel_ng_triggered/b...)
The CQ bit was checked by titzer@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from clemensh@chromium.org, mstarzinger@chromium.org Link to the patchset: https://codereview.chromium.org/2520963002/#ps140001 (title: "Fail for >= 2gb")
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": 140001, "attempt_start_ts": 1479749681308680,
"parent_rev": "a1e1304dd1b7b25a335c8082f16d185584a3543c", "commit_rev":
"5ffdde5ba6fb8bfd36545afa5aeb5348a60d5b2d"}
Message was sent while issue was closed.
Description was changed from ========== [d8] Use virtual memory to allocate large array buffers. R=mstarzinger@chromium.org,clemensh@chromium.org BUG= ========== to ========== [d8] Use virtual memory to allocate large array buffers. R=mstarzinger@chromium.org,clemensh@chromium.org BUG= ==========
Message was sent while issue was closed.
Committed patchset #8 (id:140001)
Message was sent while issue was closed.
Description was changed from ========== [d8] Use virtual memory to allocate large array buffers. R=mstarzinger@chromium.org,clemensh@chromium.org BUG= ========== to ========== [d8] Use virtual memory to allocate large array buffers. R=mstarzinger@chromium.org,clemensh@chromium.org BUG= Committed: https://crrev.com/d96131ed9bf14bd7ec13bbf19c2c6caebf851a14 Cr-Commit-Position: refs/heads/master@{#41154} ==========
Message was sent while issue was closed.
Patchset 8 (id:??) landed as https://crrev.com/d96131ed9bf14bd7ec13bbf19c2c6caebf851a14 Cr-Commit-Position: refs/heads/master@{#41154} |
