![]() ![]() 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. We have some relatively complex functions (an interpreter, etc) that should normally be very light but are exceeding stack in Safari. 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.įrom 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. 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. 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. The above line is exactly the same across all browsers including safari desktop yet we are running into some limit on mobile safari but not sure exactly where.Īny information on the above would be greatly appreciated. We get the same information for the different stack sizes reported no matter what browser we use. Is it the JavaScript stack depth or the WebAssembly stack depth? Which stack is actually exceeded to be exact. Other than onRuntimeIntialized of course as we are using that to start up the app now. Is this controllable somehow? Maybe some type of signal that says the WebAssembly module has finished doing what it is doing on mobile devices and can be called into now. This suggests that the stack is smaller on startup for some reason and then becomes available later?Ĭould this be something that is caused by the JITing/tiered JITing of the WebAssembly module when loading? The stack that is available is being used by the compilation of the WebAssembly module and then freed back up again? Same application but if a setTimeout, of a variable time from 500ms to 4 seconds depending on the device, is used before the first call it does work. The troubling part is that each mobile device has a separate variable time where it will work. I will agree that `All browsers have stack depth limits.` It is not only that it has become smaller but applications that worked before in IOS12, no longer work. ![]() The same attachments can be used from here: Please let me know if this should be filed somewhere else as this is against a Beta 13.įor a list of sites and examples to look at one can see the issue here: Is there a way to control the stack limit in mobile safari via a parameter to extend the call stack limit in mobile safari? That way users can have a way to work around the issue. These sites used to load in mobile safari 12 but no longer load in the Beta 13.įollowing the outline as described in the link above to the other issue the sites do load. The sites that do not run into the error as reported in the issue link above are running into other `RangeError: Maximum call stack size exceeded.` as well as `Unhandled Promise Rejection: RangeError: Maximum call stack size exceeded.`. The iOS 13 Beta is pretty much unusable running through mobile safari while they do load on desktop browsers including safari and android chrome. This is a follow up to the issue reported here
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |