[Webkit-unassigned] [Bug 170826] New: WebAssembly: slow memory grow should over-allocate
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Apr 13 13:48:16 PDT 2017
https://bugs.webkit.org/show_bug.cgi?id=170826
Bug ID: 170826
Summary: WebAssembly: slow memory grow should over-allocate
Product: WebKit
Version: WebKit Nightly Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: JavaScriptCore
Assignee: webkit-unassigned at lists.webkit.org
Reporter: jfbastien at apple.com
CC: fpizlo at apple.com, ggaren at apple.com,
jfbastien at apple.com, keith_miller at apple.com,
mark.lam at apple.com, msaboff at apple.com,
sbarati at apple.com
Depends on: 170628
Blocks: 159775
In bug #170628 Keth suggested:
>> Source/JavaScriptCore/wasm/WasmMemory.cpp:480
>> + void* newMemory = tryGetSlowMemory(desiredSize);
>
> I'm not sure we want to grow to the exact size. Usually you want to double up so you can avoid the pathological case of repeatedly calling grow(1).
>
> I would make this:
>
> std::min(std::max(desiredSize, m_mappedCapacity * 2), 2 << 32).
I'm not sure I agree, but I think it's worth revisiting when we have real-world data.
I'm dubious because:
- We really want to have fast memories, not slow ones.
- Emscripten is likely the one calling sbrk, so if that's the right heuristic it should already use it.
- As part of bug #170825 I'd like to impose a limit on virtual allocation of slow memories. This would bring that limit closer much faster.
- We may cause memcpy more often because mmap fails to increase the virtual address space we already have (or mremap once we address bug #170557).
Given the doubts I have I'd rather stay with what seems to be simpler for now.
I may be wrong though! If we see real-world code that suffers from this heuristic then we should reconsider.
Referenced Bugs:
https://bugs.webkit.org/show_bug.cgi?id=159775
[Bug 159775] WebAssembly: support the newer spec
https://bugs.webkit.org/show_bug.cgi?id=170628
[Bug 170628] WebAssembly: manage memory better
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170413/7bcf12c9/attachment-0001.html>
More information about the webkit-unassigned
mailing list