Bug 177392 – WebAssemly + gigacage maxNumWebAssemblyFastMemories = 10 fails

• Status: RESOLVED
• Resolution: INVALID
• Component: WebAssembly

[JF Bastien]

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.

[Filip Pizlo]

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.

[JF Bastien]

(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...

[Filip Pizlo]

(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.