Closed Bug 1599634 Opened 5 years ago Closed 4 years ago

Handle AsmJS Parsing without allocating on the GC

Categories

(Core :: JavaScript Engine, task, P1)

task

Tracking

()

RESOLVED FIXED
mozilla79
Tracking Status
firefox-esr68 --- wontfix
firefox-esr78 --- wontfix
firefox77 --- wontfix
firefox78 --- wontfix
firefox79 --- fixed

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

Note to whomever handles this: One important point is NewAsmJSModuleFunction

Priority: -- → P2

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

  1. SharedModule is not a GC type, but instead a RefPtr to a non-GC’d type, which already has its ownership handed over to the WasmModuleObject
  2. The WasmModuleObject creation only needs the shared module and context. This is great news
  3. 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 calls NewNativeConstructor. Cool! We can handle this nicely.
  4. After the clobber we do need to pass a couple of IsAsmJSModule calls, but that should be not too hard to work around.

The analysis in Comment 2 seems to hold and I have a prototype working now. Patches soon!

Assignee: nobody → tcampbell
Severity: normal → N/A
Priority: P2 → P1

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.

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

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

TODO: Remove the dummyFunction code from asm.js frontend. FunctionBox no longer requires it.

Keywords: leave-open
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
Regressions: 1643902

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

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
Status: NEW → RESOLVED
Closed: 4 years ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → mozilla79
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: