[Webkit-unassigned] [Bug 173908] New: WebAssembly: don't tier up when out of executable memory
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Tue Jun 27 23:47:26 PDT 2017
https://bugs.webkit.org/show_bug.cgi?id=173908
Bug ID: 173908
Summary: WebAssembly: don't tier up when out of executable
memory
Product: WebKit
Version: WebKit Nightly Build
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: JavaScriptCore
Assignee: webkit-unassigned at lists.webkit.org
Reporter: jfbastien at apple.com
CC: fpizlo at apple.com, jfbastien at apple.com,
keith_miller at apple.com, mark.lam at apple.com,
msaboff at apple.com, sbarati at apple.com
Depends on: 171537
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.
Referenced Bugs:
https://bugs.webkit.org/show_bug.cgi?id=171537
[Bug 171537] WebAssembly: running out of executable memory should throw OoM
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170628/e5c86530/attachment.html>
More information about the webkit-unassigned
mailing list