[Webkit-unassigned] [Bug 201028] [WebAssembly] iOS 13 RangeError: Maximum call stack size exceeded.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=201028

Katelyn Gadd <kg at luminance.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kg at luminance.org

--- Comment #5 from Katelyn Gadd <kg at luminance.org> ---
Just to clarify: The maximum stack depth for WASM in Safari appears to change depending on elapsed time, which would seem to be caused by the tiered JIT. It makes sense that JIT behavior would have changed between 12 and 13, especially because I've seen posts on the WebKit blog to suggest that changes have occurred.

The amount of time we need to wait seems to vary across devices (likely based on specs?) which adds weight to our theory that this is based on tiered jit.

>From examining some of the details of the first tier (BBQ - build bytecode quickly? I can't remember the name) it seems like it could end up generating more stack bloat for complex functions than the final tier does. We have some relatively complex functions (an interpreter, etc) that should normally be very light but are exceeding stack in Safari. Basic tests with simple modules show that we can recurse quite far so it doesn't seem like we're hitting any trivial stack limits here - WASM can in fact recurse much further in Safari than it can in Chrome or Firefox - but instead the code generation seems to be really bad for some corner case we're hitting here.

Is there a way to manually reproduce the behavior of the first tier jit without the later tiers? I saw a mix of compile flags when digging through the WebKit source but it's very hard to understand all these systems, there aren't particularly detailed comments and I couldn't find any documentation of what flags iOS or OS X safari build JSC with.

-- 
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/20191021/dd65ce82/attachment-0001.html>