170826 2017-04-13 13:48:16 -0700 WebAssembly: slow memory grow should over-allocate 2017-04-13 13:48:16 -0700 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build Unspecified Unspecified NEW https://bugs.webkit.org/show_bug.cgi?id=170557 P2 Normal --- 170628 159775 1 jfbastien webkit-unassigned fpizlo ggaren jfbastien keith_miller mark.lam msaboff saam oldest_to_newest 1297121 0 jfbastien 2017-04-13 13:48:16 -0700 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.