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: mono/mono#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 #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?

[pranavkm]

@SteveSandersonMS is this still relevant?

[ghost]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment. If it is closed, feel free to comment when you are able to provide the additional information and we will re-investigate.

See our Issue Management Policies for more information.

[StachuDotNet]

@SteveSandersonMS is this still relevant?

Yes - just experienced this in an AOT release build, .NET 6.0.300.
May have been some absurd edge case - not sure yet - will follow up.

---

Edit: Small follow-up: we're only able to replicate this in AOT Release builds.
(Debug builds, no issue. Non-AOT Release builds, no issue)

The payload in question is rather large - 70.8kB of JSON - may or may not be a factor.
If it is a factor, this StackOverflow answer may prove useful: https://stackoverflow.com/a/57973792

We've yet to resolve the issue for our case, but have a few leads. I'll edit this comment with any useful information I find, as to not spam the thread with additional comments.

---

Edit: My issue may or may not have been relevant to this Issue, but is certainly not related to the payload size as I earlier claimed. An external Issue linked is below, in case someone else encounters a mystery error in this space in the future.

[SteveSandersonMS]

This old issue isn't tracking any actual pending action so I'll close it to keep the backlog clearer.

The closest issue related to wasm memory limits is #42055