[Webkit-unassigned] [Bug 256703] [iOS] Wasm based WebApp readalong.google.com reproducibly jetsams

[bugzilla-daemon at webkit.org]

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

--- Comment #16 from tasnim <tasnimrock2k6 at gmail.com> ---
(In reply to Justin Michaud from comment #13)
> 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.
Thanks! can you link bugs / PR here as you work through just so that we are aware of such improvements and can experiment against them.
> 
> 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.
These are actually managed by flutter web framework. I will get back if I find anything but I am expecting these to be not leaked. Also, we have experimented with just the flutter web app (without wasm). It works perfectly fine on iOS. Maybe we might be just close to the memory limit but the browser never reloads as pulkit mentioned initially in the thread. 
> 
> 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.
Earlier, we were doing non_simd variant of wasm for safari but safari now supports simd (https://developer.apple.com/documentation/safari-release-notes/safari-16_4-release-notes) and so, both are getting the same binary.
> 
> 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.
> 
Let me get back on this. How are you verifying on chrome? I was using performance.measureUserAgentSpecificMemory but it doesn't seem to correctly report back the memory. I think that over counts the SharedArrayBuffer (wasm memory) that's shared across the web workers.

> 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.
Thanks, yeah we are looking into this including lowering of the compiled wasm size.
> 
> 
> 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.
Just curious: we need to work on this but how much of this will actually help. I know this will help in lowering the memory usage but not sure by how much? Based on our experiments, we tried against starting with few web workers and it was still easily crashing on iOS safari.

-- 
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/20230523/1d2c88ba/attachment-0001.htm>