Handle AsmJS Parsing without allocating on the GC
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
People
(Reporter: mgaudet, Assigned: tcampbell)
References
Details
Attachments
(4 files)
There are certain aspects of the AsmJS that have been special-cased for the purposes of making forward progress on this project, but in order to finish we will have to handle AsmJS eventually
Reporter | ||
Comment 1•5 years ago
|
||
Note to whomever handles this: One important point is NewAsmJSModuleFunction
Updated•4 years ago
|
Reporter | ||
Comment 2•4 years ago
|
||
The case is nowhere near as hopeless or concerning as I had previously thought. Further investigation suggests the key aspects are here: https://searchfox.org/mozilla-central/rev/e7fc3314b0dfcc61fb7dc7a09f9555660a2eafc5/js/src/wasm/AsmJS.cpp#7094,7101,7111,7121
SharedModule
is not a GC type, but instead a RefPtr to a non-GC’d type, which already has its ownership handed over to theWasmModuleObject
- The
WasmModuleObject
creation only needs the shared module and context. This is great news - The allocation of the module function -does- currently take the
FunctionBox
, but from this needs literally only the name, lambda status, and the nargs. From that it callsNewNativeConstructor
. Cool! We can handle this nicely. - After the clobber we do need to pass a couple of
IsAsmJSModule
calls, but that should be not too hard to work around.
Assignee | ||
Comment 3•4 years ago
|
||
The analysis in Comment 2 seems to hold and I have a prototype working now. Patches soon!
Assignee | ||
Comment 4•4 years ago
|
||
Use InitialFunctionFlags to compute flags consistently. That requires
plumbing FunctionSyntaxKind in for the standalone-function case. Preserve the
existing expression-vs-statement decisions. We move the InitialFunctionFlags
definition earlier in file but it is unchanged.
Stop allocating a function before parsing and rely on the frontend to do that
for us. This gives more consistent behaviour with asm.js and inner functions.
We need to explicitly call initEnvironment function now since the Stencil
instantiation code does not do it for us, while NewScriptedFunction did.
Assignee | ||
Comment 5•4 years ago
|
||
Also add JS::WasmModule::createObjectForAsmJS
which is similar to
createObject
but does not set the WasmModule prototype. Also mark these
methods as const so they work with the SharedModule
definition.
Depends on D78087
Assignee | ||
Comment 6•4 years ago
|
||
Avoid allocating the JSFunction / WasmModuleObject for asm.js during parsing,
but continue to generate the JS::WasmModule (which does not use GC). Add a
map to the CompilationInfo to keep track of these modules until stencils are
being instantiated.
Depends on D78088
Assignee | ||
Comment 7•4 years ago
|
||
TODO: Remove the dummyFunction code from asm.js frontend. FunctionBox no longer requires it.
Pushed by tcampbell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/afada3b4e234 Stop pre-allocating JSFunction for standalone compiles r=mgaudet https://hg.mozilla.org/integration/autoland/rev/834b400f034f Move the JS::WasmModule definition to own header r=bbouvier
Comment 9•4 years ago
|
||
bugherder |
Assignee | ||
Comment 10•4 years ago
|
||
These days, FunctionBox can be created without a JSFunction which is also
suitable for the asm.js dummyFunction case. Remove the function and pass name
and flags directly to the FunctionBox.
We set flags to INTERPRETED_NORMAL since that is only type of function
allowed at this point in the asm.js context.
Depends on D78089
Comment 11•4 years ago
|
||
Pushed by tcampbell@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ff4b77aae2f9 Defer JSFunction allocation for asm.js modules r=djvj https://hg.mozilla.org/integration/autoland/rev/57fdda3872e8 Remove dummyFunction from asm.js. r=bbouvier,djvj
Comment 12•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Description
•