Bug 173908
| Summary: | WebAssembly: don't tier up when out of executable memory | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | JF Bastien <jfbastien> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | fpizlo, jfbastien, keith_miller, mark.lam, msaboff, saam |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 171537 | ||
| Bug Blocks: | |||
JF Bastien
In https://bugs.webkit.org/show_bug.cgi?id=171537 I made our implementation throw when instantiating a new module fails because there isn't enough executable memory. I also made it abort the installation of a tiered up function if we run out of executable memory.
I now want to make sure that the second case (tier up fail) doesn't end up in infinite recompile.
A few ideas:
- Before compiling for tier up, check that at least $SOMETHING executable memory is available, where $SOMETHING is a heuristic we pick (percentage of total?).
- Before compiling for tier up, check that at least $MULTIPLE * (end - start) executable memory is available, where (end - start) refer to the original binary, and $SOMETHING is a number we can measure from compiling existing code (average or max of what we typically see).
- Connect with the GC better, maybe we can clean things up and find more executable memory (similar to what I did to WebAssembly.Memory + GC?).
We can do all or some of these, and base tier up backoff on these heuristics.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Saam Barati
We won’t infinite loop today. We’ll only compile something once. That said, it might be worth avoiding a compilation all together if we don’t have X memory. That said, this scenario is pretty unlikely, so whatever we do there will mostly be untested code.