[Webkit-unassigned] [Bug 256703] [iOS] Wasm based WebApp readalong.google.com reproducibly jetsams
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon May 22 11:15:29 PDT 2023
https://bugs.webkit.org/show_bug.cgi?id=256703
--- Comment #13 from Justin Michaud <justin_michaud at apple.com> ---
Hey! Thanks again for reporting this. I am currently in the process of working on some general memory improvements, and I will investigate this after they land.
Looking at Inspector, I have a few questions. I believe that this could be caused by a few reasons, and it would be super helpful if you could rule them out.
1) I see that you have a bunch of arrays of canvases. Do you ever clear those? Can you confirm that they aren't being leaked?
The hypothesis here would be that they are always reachable, and therefore never collected. This could also explain why so much "page" memory is being used.
2) Can you confirm that you are serving the same binary to Safari as to Chrome, and that both engines are going down the same code path? For example, one way that this behaviour could be explained is if readalong is using some fallback path for tts, but using a Chrome API that is way more efficient on Chrome.
I am seeing that on Chrome, you are allocating a bunch of SharedArrayBuffers, but there are none in the heap on Safari.
I am also seeing that the JS heap according to inspector is 900mb on Safari, but only 300mb on Chrome.
Another example that I've seen before with emscripten is that it could be taking a slow path because it doesn't detect the browser properly. For example, I could imagine a scenario where on Chrome, emscripten uses a weak map for something but falls back to the default case on Safari.
3) Perhaps we have a memory leak. I can do some debugging on my end.
4) Of course, WebKit could just be using more memory in general. I am working on fixing that now, but the most actionable thing for you to do to get results quickly would be to lower your overall memory usage by clearing caches, breaking reference to large data, and making sure that you don't hold on to references to big native objects like canvas.
I also have noticed that you are using 20 workers. That number seems to be a bit excessive. Note that Safari won't give you an accurate core count for fingerprinting reasons, so perhaps reducing this might be a quick way to work around this issue for now.
--
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/20230522/21eb1b30/attachment.htm>
More information about the webkit-unassigned
mailing list