Bug 173908 - WebAssembly: don't tier up when out of executable memory
Summary: WebAssembly: don't tier up when out of executable memory
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 171537
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-27 23:47 PDT by JF Bastien
Modified: 2017-06-28 00:50 PDT (History)
6 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description JF Bastien 2017-06-27 23:47:26 PDT
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.
Comment 1 Saam Barati 2017-06-28 00:50:35 PDT
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.