Aspnetcore: Apply default memory limit in Mono env

[SteveSandersonMS]

Recommendation from @kumpera is to set it at 128MB initially, allowing the developer to change that setting for their app if they want.

If we don't do this, and the app exceeds the amount of memory the browser wishes to give, then it fails with an obscure error instead of an OutOfMemoryException.

Note to self: to set env vars for the Mono wasm runtime, call something like the following from JS before the runtime starts.

MONO.mono_wasm_setenv ("MONO_LOG_MASK", "all");

[andoband]

I see that the WebAssembly Memory API has a grow() method. It might be nice if Mono had the option to request more memory from the browser before failing. Or even just some hooks for app developers to monitor memory usage and request more on Mono's behalf.

[kumpera]

@andoband mono uses that API already, that's how memory is allocated. The issue here is something else and can be summarized by two key points:

• if a limit is not set, mono's gc will try to use all available memory and that almost always leads to hard crashes. We spent years trying to "use all memory but not all memory" for no avail, it's unreliable and always produces surprising results.

• The actual amount of available memory is undefined, WebAssembly can grown up to 4Gb, but how much they will actually provide is unspecified.

[andoband]

@kumpera Good to know...thanks!

[SteveSandersonMS]

Further note from Marek:

Its MONO_GC_PARAMS, see 'man mono' for the possible values. Also, the changes are not yet in mono master, they are in this PR: https://github.com/mono/mono/pull/11314

[kant2002]

Does that mean that for Client-side Blazor would be possible to have some browser specific API like SetMemoryLimit(128 * 1024 * 1204) which I, as developer, could call on the application startup ?

[moataz1991]

im sorry but im stuck !
when we will be able to attach large files in blazor client side ?

[javiercn]

See https://github.com/aspnet/AspNetCore/issues/16692 for the GC being too aggressive as a potential outcome of this.

[legistek]

I'm sure it's related, but the GC might be too aggressive even leaving aside the memory limits. Even with memory usage in the 20-30MB range I'm getting frequent, blocking GCs and LOS overflows:

Incidentally I tried GC.TryStartNoGCRegion during render tree building but I wound up with NotImplementedExceptions.

[Herdo]

@legistek Coming from #5466 and this:

This is the only GC log I see in the console:

[legistek]

Hm your issue might not be related then. But overall, Blazor's biggest performance bottleneck definitely seems to be in building very complex DOMs. One would assume AOT would help with that significantly. That said, because the WASM designers inexplicably chose not to give WASM direct access to the DOM, it's always going to require JS interop, which is always going to be an issue.

[legistek]

This doesn't seem to have been addressed (at least not fully) in the official release of Blazor WASM. I still get a lot of instances of the below, accompanied by very noticeable freezes in the app:

Granted I am trying to build a complex DOM but nothing that a native JS framework couldn't handle easily. Can't the GC settings be tweaked to allow more RAM usage before app-freezing GCs take place?

Will the GC occur in a background thread ultimately once multithreading is implemented?

[Stamo-Gochev]

What is the expected milestone for this? Will it be reconsidered as wasm is now officially supported?