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)
Core
JavaScript: WebAssembly
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: luke, Assigned: luke)
References
Details
Attachments
(1 file)
652.25 KB,
application/zip
|
Details |
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.
Comment 1•10 years ago
|
||
Will this mean there will be a max script size limit after which asm.js will not validate?
Assignee | ||
Comment 2•10 years ago
|
||
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.
Comment 3•6 years ago
|
||
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
Updated•6 years ago
|
Status: RESOLVED → REOPENED
Resolution: INACTIVE → ---
Updated•5 years ago
|
Component: JavaScript Engine → Javascript: WebAssembly
Comment 4•5 years ago
|
||
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 ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•