[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 #26 from tasnim <tasnimrock2k6 at gmail.com> ---
(In reply to Justin Michaud from comment #24)
> Hi folks.
> 
> I checked again, and it seems that now the JS heap snapshots look very
> similar between Chrome and Safari (384MB vs 322MB, and composed of the same
> kinds of objects).
> 
> To me, it is important to rule out different js code paths, so I’m happy
> that this is now fixed.
>  
> > Justin, you mentioned about some general memory improvements, any updates or
> > ETA on that?
> 
> Apple does not comment on future releases. We are always working on
> improving memory and performance, but I can't really predict when that work
> will land or ship. In any case, since the JS heaps are the same size now,
> these improvements will not affect your use case.
> 
> > 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. 
> 
> Can you please verify that there is no substantial difference in memory
> usage in the flutter web app without wasm between Chrome and Safari?
Yeah, should be same.
> 
> Overall: Safari is still using substantially more memory than chrome, and it
> is not coming from the JS heap.
> 
> I disabled gigacage, enabled Malloc Stack Logging, and enabled malloc heap
> breakdown in my local release build. This should give us the maximum insight
> into allocations.
> ```
> 1005 MallocStackLogging=lite __PC_MallocStackLogging=lite
> DYLD_FAMEWORK_PATH=/Volumes/WebKit/ReleaseVersion/OpenSource/WebKitBuild/
> Release
> __XPC_DYLD_FAMEWORK_PATH=/Volumes/WebKit/ReleaseVersion/OpenSource/
> WebKitBuild/Release
> /Volumes/WebKit/ReleaseVersion/OpenSource/WebKitBuild/Release/Safari.app/
> Contents/MacOS/Safari 
>  1006  /usr/bin/notifyutil -p org.WebKit.lowMemory
>  1007  /usr/local/bin/mempurge
>  1008  leaks --physFootprint --outputGraph foo.memgraph 3648
>  1009  heap foo.memgraph -s
> ```
> 
> In this configuration, I see 1.9gb total, which is way more than Chrome.
> Here are the biggest objects:
> 
> 500mb JS heap
> 157mb NativeJITCode
> 116mb JSC::Wasm::Instance::initElementSegment
> 88mb JSC::Wasm::Table::tryCreate
> 78mb JSC::WeakBlock::create
> 44mb malloc in WTF::HashTable<JSC::Weak<JSC::NativeExecutable>,
> JSC::Weak<JSC::NativeExecutable>, WTF::IdentityExtractor,
> JSC::JITThunks::WeakNativeExecutableHash,
> WTF::HashTraits<JSC::Weak<JSC::NativeExecutable>>,
> WTF::HashTraits<JSC::Weak<JSC::NativeExecutable>>>::rehash(unsigned int,
> JSC::Weak<JSC::NativeExecutable>*) 
> 60mb LLInt bytecode
> 28mb realloc in JSC::CodeBlock::CodeBlock
> 
> I am playing around with my local build. I am definitely failing to
> symbolicate some allocations. I an explain only a small portion of the
> memory difference so far. I will keep you updated.
Thanks let us know. Additionally, wanted to ask if we could get more insights on large "page" memory and something that we could investigate at our end to fix. I have attached timeline screenshot of our web app (without wasm, see safari_timeline_page). On https://bugs.webkit.org/show_bug.cgi?id=256703#c13, you mentioned it maybe due to too many "canvas" but just asking if there are others that maybe contributing here.

-- 
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/20230621/854cd474/attachment.htm>