[WASM] ... has memory leaks

[DierkDroth]

Current behavior

This is in continuation of this discussion. To my surprise it actually was quite simple to create a repo which would demonstrate the problem and chase UNO WASM into an 'OutOfMemory' scenario.

I'll spare the memory profiling for the sake of simplicity. Attached repo should release memory properly between iterations, but apparently doesn't. Please start the solution in VS, take a look at the comments in MainPage.cs and run it as UNO WASM head. Make sure to open the browser console by F12.

What am I doing wrong there?

Minimal.zip

Expected behavior

No response

How to reproduce it (as minimally and precisely as possible)

No response

Workaround

No response

Works on UWP/WinUI

None

Environment

Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia

NuGet package version(s)

No response

Affected platforms

No response

IDE

No response

IDE version

No response

Relevant plugins

No response

Anything else we need to know?

No response

[DierkDroth]

@jeromelaban I consider memory leaks one of the most serious issues in any software technology - I'm not sure what your perspective is though... and I'm actually surprised that there is no reaction whatsoever by the UNO team on my report/repo.

In particular I would like to know:

• am I doing something wrong on how I'm using the UNO technology in the repo? If yes, where in documentation would I find relevant statements on what to do and what not to do 'to avoid' memory leaks?
• are memory leaks actually a known limitation of the UNO technology in general?
• would other UNO heads than WASM (iOS, Android,...) experience similar memory leaks if one would run my repo on them?
• provided I'm using UNO correctly in my repo and in fact there are memory leaks with the UNO technology - does the UNO team have any plans to address that major problem?

Thanks in advance for your attention on this serious issue.

[DierkDroth]

@jeromelaban @MartinZikmund I just ran the repo above on latest UNO WASM 5.4.

Good news:

• it appears to be visually faster - at least in DEBUG mode on VS
• the app stays alive longer before bailing out with OutOfMemory exceptions - probably related to promoted memory management with UNO 5.4 = less stress on the garbage collector?!?

Bad news though: the memory leaks still exists.

Am I doing something fundamentally wrong with my repo? or are memory leaks a known issue with UNO (WASM)?

[jeromelaban]

@DierkDroth thanks for providing an update on 5.4. Our answer is the same as before with related discussions, we are not aware of specific memory leaks, and we need specific repros that demonstrates leaks to fix them.

You can use the tools (Here and here) mentioned previously to determine ways to create repro cases from your own environment.

[DierkDroth]

@jeromelaban I provided you repo above which demonstrates the problem: UNO WASM runs into an OutOfMemory scenario although from my (simple) repo code all memory should be 'freed'. The repo is a simplification of my actual app where grids are populated and cleared from their data.

Could you please elaborate why an UNO WASM repo is not what you needed to reproduce/analyze an issue?

[jeromelaban]

@DierkDroth My apologies, I missed that there was a repro at the top. I ran your repro, and I can see the behavior that you're seeing.

The issue here is that the allocated memory is overwhelming the GC pushing it closer to the 1.5GB memory limit of WebAssembly, and the GC seems to be out of its normal thresholds to run properly.

If you add the following line:

await Task.Delay(500);
Console.WriteLine($"GC:{GC.GetTotalMemory(true) / 1024.0 / 1024.0}");

Which forces the GC to run, your repro can run indefinitely, as the GC collects released memory as part of reading of the available memory. This indicates that there is no existing memory leak for the scenario from this repro.

You may want to experiment with the .NET GC parameters, as explained here, then run the GC explicitly when you know that there are large allocations that are released.

[DierkDroth]

Thanks for looking into @jeromelaban. Much appreciated.

Wow that's interesting ... so the .NET WASM GC (Mono runtime) would not trigger by itself, although it's running out of memory, but needed to be called explicitly ?!? ... I consider this a strange GC strategy

I browsed through the list of parameters your provided (thanks!) but could not spot any parameter which would force the GC to "get its job done" when it's starving on memory. Would you have any hint/pointer?

[jeromelaban]

I browsed through the list of parameters your provided (thanks!) but could not spot any parameter which would force the GC to "get its job done" when it's starving on memory. Would you have any hint/pointer?

This may be a question better suited for the dotnet/runtime repo, but we generally set values similar to the ones in this section in apps. It may not necessarily work properly for starvation, but it's worth a try.

[DierkDroth]

Thanks @jeromelaban. I'll look into ...

FYI: adding <WasmShellMonoEnvironment Include="MONO_GC_PARAMS" Value="soft-heap-limit=512m,nursery-size=64m,evacuation-threshold=66,major=marksweep" /> does not improve the situation.