Bug 170826 - WebAssembly: slow memory grow should over-allocate
Summary: WebAssembly: slow memory grow should over-allocate
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
Depends on: 170628
Blocks: 159775
  Show dependency treegraph
Reported: 2017-04-13 13:48 PDT by JF Bastien
Modified: 2017-04-13 13:48 PDT (History)
7 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description JF Bastien 2017-04-13 13:48:16 PDT
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.