408d89041e
Allow mocking the limits for ArrayBuffer allocation to simulate operating
system OOM.
Fixes:
- Ensure OS limit > hard limit for external memory. This is necessary as
any processing below the hard limit is opportunistic. E.g. a running
sweeper may stall the current marking (GC) round.
- Immediately process AB allocations when under memory pressure. Otherwise,
the allocations may be stuck in a stalled task. Freeing them upon
adding them to the collector still enables parallelism if possible.
This reverts commit f3ad6cdb9c.
Bug: chromium:845409
Change-Id: Ic3e458f2af231bae3d53afcfd6002a0347d3f12b
Reviewed-on: https://chromium-review.googlesource.com/1206872
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55656}
14 lines
562 B
JavaScript
14 lines
562 B
JavaScript
// Copyright 2018 the V8 project authors. All rights reserved.
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
// found in the LICENSE file.
|
|
|
|
// Flags: --mock-arraybuffer-allocator --mock-arraybuffer-allocator-limit=1300000000
|
|
|
|
// --mock-arraybuffer-allocator-limit should be above the hard limit external
|
|
// for memory. Below that limit anything is opportunistic and may be delayed,
|
|
// e.g., by tasks getting stalled and the event loop not being invoked.
|
|
|
|
for (var i = 0; i < 1536; i++) {
|
|
let garbage = new ArrayBuffer(1024*1024);
|
|
}
|