[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 #24 from Justin Michaud <justin_michaud at apple.com> ---
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?

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.

-- 
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/be669e08/attachment.htm>