wasm: Inlining budgets for functions and for entire modules
Categories
(Core :: JavaScript: WebAssembly, enhancement, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox134 | --- | fixed |
People
(Reporter: jseward, Assigned: jseward)
References
Details
Attachments
(1 file)
Our inliner is pretty aggressive. It is easy to write a small recursive
function that requires 125MB of memory for Ion to compile at the default
inlining settings, and more than 15GB at wasm_inlining_level=8, which is not
even the highest inlining level. Such a function could be used as the basis
for an OOM DOS attack, so this scenario needs to be guarded against.
I am inclined to implement the following:
-
no function can have an inlining-based expansion of more than a constant
factor (say 10 x). -
for a module as a whole there is also a max expansion factor, and this is
much lower, perhaps 2 x.
This means that
-
no individual function can cause too much trouble (due to the 10 x limit),
yet any function that needs a lot of inlining can still get it. In
practice most functions have an inlining expansion, at default settings, of
much less than 5 x. -
the module as a whole cannot chew up excessive resources
Once a limit is exhausted, Ion compilation is still possible, but no inlining
will be done.
The per-module limit needs to be interpreted in the light of lazy tiering.
Many modules only tier up a small subset of their functions. Hence the
relatively low per-module limit still allows a high level of expansion of the
functions that do get tiered up.
In effect, the tiering mechanism gives hot functions (early tierer-uppers)
preferential access to the module-level inlining budget. Colder functions that
tier up later may find the budget to be exhausted, in which case they get no
inlining. I guess it would be possible to gradually reduce inlining
aggressiveness as the budget is used up, rather than have cliff-edge behaviour,
but it hardly seems worth the hassle.
|
Assignee | |
Comment 1•1 year ago
|
||
Our inliner is pretty aggressive. It is easy to write a small recursive
function that requires 125MB of memory for Ion to compile at the default
inlining settings, and way more at higher inlining levels.
To guard against OOMs and generally unreasonable behaviour, this patch
introduces inlining budgets both at a per-function and per-module level. With
current settings, no function can have an inlining-based expansion of more than
10 x (when measuring wasm bytecode), and no module may be more than doubled in
size. If a limit is exceeded, inlining is disabled for the offending
function/module, but compilation via Ion is still allowed.
There are more details in a [SMDOC] in the patch.
As a drive-by fix, FunctionCompiler::stats is renamed to stats_ in keeping
with the usual naming conventions.
|
||
Comment 3•1 year ago
|
||
| bugherder | ||
Description
•