Closed Bug 875174 Opened 11 years ago Closed 5 years ago

OdinMonkey: fall back to baseline jit for enormous functions

Categories

(Core :: JavaScript: WebAssembly, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: luke, Assigned: luke)

References

Details

Attachments

(1 file)

Attached file bad compile times 1
When functions get incredibly large, Ion starts to exhibit quadratic behavior in time and space usage.  This is fine normally, since these functions just get denied by the Ion compilation heuristics.  Odin, OTOH, currently Ion-compiles everything.  Fortunately, most codebases don't come anywhere close to the limit, but we are starting to find cases that do.  (One is the bison-generated yyparse (bug 864587), another is an Intel face-detection code, attached.)

A straightforward solution is to just fallback to the baseline jit in the case of these huge functions.  That's made a little difficult by the fact that we don't create bytecode for anything in an asm.js module.  However, we should be able to produce a JSScript on demand (for just the huge function) by reusing the lazy-bytecode work in bug 678037.
Blocks: 881537
Will this mean there will be a max script size limit after which asm.js will not validate?
Well, it'd "validate", but it'd just run in the baseline jit which is 2-20x slower.  This would be good for the case of huge cold functions, but still bad for hot ones (like say, big interpreter loops) so the developer would still need to cut the function into smaller pieces in that case.

Emscripten's outlining feature made this feature much less of a priority, btw.  A related feature I wish Emscripten could grow is to be able automatically move functions outside the asm.js module.  This could give developers another tool for managing the load-time of cold code.  In my wildest dreams, you could have Emscripten generate a profiling build that generates a list of cold functions which could then be moved outside of the asm.js module.  With asm.js caching, though, it's *still* possible that keeping these in the asm.js module would overall be faster.
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → INACTIVE
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Component: JavaScript Engine → Javascript: WebAssembly

Closing: asm.js is becoming less and less relevant. For wasm, tiering circumvents the issue, and heuristics already decide how to compile functions. If we wanted to have recompilation-by-baseline when we see a very large function that takes too long for Ion to compile, we could open another bug (? if there's not a bug open already).

Status: REOPENED → RESOLVED
Type: defect → enhancement
Closed: 6 years ago5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: