Set maxNumWebAssemblyFastMemories to 10, then run: ./Tools/Scripts/run-javascriptcore-tests --debug --filter=wasm --quick --no-build --no-testapi --no-testmasm --no-testb3 --no-testair Or just: (cd ./JSTests/wasm/ && DYLD_FRAMEWORK_PATH=$d/WebKitBuild/$type/ $d/WebKitBuild/$type/jsc -m ./js-api/dont-mmap-zero-byte-memory.js) This fails in gigacage allocation when trying to allocate a fast memory, because it expects that allocation to succeed and it RELEASE_ASSERTs out. I didn't investigate, but it shouldn't fail (it's a virtual allocation), and it should fall back to slow memory if so.
Not a bug. The purpose of maxNumWebAssemblyFastMemories is to protect us from this case by ensuring the we don’t ever eat up all of the gigacage just with virtual allocations.
(In reply to Filip Pizlo from comment #1) > Not a bug. The purpose of maxNumWebAssemblyFastMemories is to protect us > from this case by ensuring the we don’t ever eat up all of the gigacage just > with virtual allocations. Options processing should catch an invalid input for maxNumWebAssemblyFastMemories then, no? x86 used to be able to have a huge number of fast memories...
(In reply to JF Bastien from comment #2) > (In reply to Filip Pizlo from comment #1) > > Not a bug. The purpose of maxNumWebAssemblyFastMemories is to protect us > > from this case by ensuring the we don’t ever eat up all of the gigacage just > > with virtual allocations. > > Options processing should catch an invalid input for > maxNumWebAssemblyFastMemories then, no? x86 used to be able to have a huge > number of fast memories... It is not a goal of options processing to catch all nonsensical inputs. Also, the right maximum here is terribly difficult to deduce.