Bug 170826
| Summary: | WebAssembly: slow memory grow should over-allocate | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | JF Bastien <jfbastien> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | fpizlo, ggaren, jfbastien, keith_miller, mark.lam, msaboff, saam |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=170557 | ||
| Bug Depends on: | 170628 | ||
| Bug Blocks: | 159775 | ||
JF Bastien
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |