Blazor WASM does not free memory - possibly a memory leak

[jahnotto]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When allocating large arrays in Blazor wasm 6.0.1, the memory is never freed up when the reference is set to null. Consecutive allocations ends up with an OutOfMemoryException.

Either I'm doing something very wrong, or there is a memory leak.

Expected Behavior

The GC should free the memory that is no longer used, and should not result in an OutOfMemoryException.

Steps To Reproduce

Minimal repro project is here: https://github.com/jahnotto/BlazorWasmMemoryIssue

Try to click multiple times on "Allocate DotNet memory". The memory keeps increasing. Clicking "Free DotNet memory" does not make any difference. Same behavior is seen in debug, release and even AOT.

Allocating JS memory, on the other hand, works as expected.

Exceptions (if any)

OutOfMemoryException

.NET Version

6.0.101

Anything else?

Blazor wasm 6.0.1
Tested on both Edge and Chrome

Note: GCSettings.GCLatencyMode is set to Batch in Blazor wasm and can't be changed. I don't know if this relevant, but I'd expect it to be Interactive for an interactive client side application.

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When allocating large arrays in Blazor wasm 6.0.1, the memory is never freed up when the reference is set to null. Consecutive allocations ends up with an OutOfMemoryException.

Either I'm doing something very wrong, or there is a memory leak.

Expected Behavior

The GC should free the memory that is no longer used, and should not result in an OutOfMemoryException.

Steps To Reproduce

Minimal repro project is here: https://github.com/jahnotto/BlazorWasmMemoryIssue

Try to click multiple times on "Allocate DotNet memory". The memory keeps increasing. Clicking "Free DotNet memory" does not make any difference. Same behavior is seen in debug, release and even AOT.

Allocating JS memory, on the other hand, works as expected.

Exceptions (if any)

OutOfMemoryException

.NET Version

6.0.101

Anything else?

Blazor wasm 6.0.1
Tested on both Edge and Chrome

Note: GCSettings.GCLatencyMode is set to Batch in Blazor wasm and can't be changed. I don't know if this relevant, but I'd expect it to be Interactive for an interactive client side application.

Author:	jahnotto
Assignees:	-
Labels:	area-GC-coreclr, untriaged
Milestone:	-

[mangod9]

hi @SamMonoRT could you please suggest what area this could be moved under?

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When allocating large arrays in Blazor wasm 6.0.1, the memory is never freed up when the reference is set to null. Consecutive allocations ends up with an OutOfMemoryException.

Either I'm doing something very wrong, or there is a memory leak.

Expected Behavior

The GC should free the memory that is no longer used, and should not result in an OutOfMemoryException.

Steps To Reproduce

Minimal repro project is here: https://github.com/jahnotto/BlazorWasmMemoryIssue

Try to click multiple times on "Allocate DotNet memory". The memory keeps increasing. Clicking "Free DotNet memory" does not make any difference. Same behavior is seen in debug, release and even AOT.

Allocating JS memory, on the other hand, works as expected.

Exceptions (if any)

OutOfMemoryException

.NET Version

6.0.101

Anything else?

Blazor wasm 6.0.1
Tested on both Edge and Chrome

Note: GCSettings.GCLatencyMode is set to Batch in Blazor wasm and can't be changed. I don't know if this relevant, but I'd expect it to be Interactive for an interactive client side application.

Author:	jahnotto
Assignees:	-
Labels:	arch-wasm, area-GC-coreclr, untriaged
Milestone:	-

[SamMonoRT]

@BrzVlad @lewing @vargaz

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When allocating large arrays in Blazor wasm 6.0.1, the memory is never freed up when the reference is set to null. Consecutive allocations ends up with an OutOfMemoryException.

Either I'm doing something very wrong, or there is a memory leak.

Expected Behavior

The GC should free the memory that is no longer used, and should not result in an OutOfMemoryException.

Steps To Reproduce

Minimal repro project is here: https://github.com/jahnotto/BlazorWasmMemoryIssue

Try to click multiple times on "Allocate DotNet memory". The memory keeps increasing. Clicking "Free DotNet memory" does not make any difference. Same behavior is seen in debug, release and even AOT.

Allocating JS memory, on the other hand, works as expected.

Exceptions (if any)

OutOfMemoryException

.NET Version

6.0.101

Anything else?

Blazor wasm 6.0.1
Tested on both Edge and Chrome

Note: GCSettings.GCLatencyMode is set to Batch in Blazor wasm and can't be changed. I don't know if this relevant, but I'd expect it to be Interactive for an interactive client side application.

Author:	jahnotto
Assignees:	-
Labels:	arch-wasm, untriaged, area-GC-mono
Milestone:	-

[BrzVlad]

I'm not convinced this is a leak, simply because the array size is very large relative to the maximum memory size. The GC is not really deterministic: objects can sometimes remain pinned and not get collected, the GC can therefore increase the trigger limit for next collection and the memory usage can spiral out of control.

@jahnotto Could you please test the behavior with a smaller array size like 128MB ? If you do iterations of Alloc/Free would you ever encounter unbounded memory growth ?

[Fabi]

It's an issue in server and client side blazor. Even trying to force collecting memory won't work. it's all referenced somewhere in native memory behind the scenes. This is expected behavior according to all these MS guys but it should NOT happen. For months users are just getting blamed to wait for the GC to collect memory because stuff gets freed very late or never at some point or when you run out of memory. This should get fixed ASAP!

[jahnotto]

Thanks for following up @BrzVlad . I have done some more testing.

1. Allocating 128 MB instead of 512 MB seems to work better. The memory keeps increasing, but only up to a certain point. I'm not getting an exception anymore.
2. I have added a WPF test project in the repro project which is doing exactly the same thing (with 512 MB allocations). Here you can see that the GC is behaving very differently than in Blazor:

• Memory is increasing until a certain point, but does not result in an exception
• If I call GC.Collect(), the memory is freed. This seems to have no effect in Blazor
• GCSettings.LatencyMode is Interactive, as opposed to Batch in Blazor.

Edit @BrzVlad Not sure what you mean by "iterations of alloc/free"? I'm clicking allocate and free multiple times. With big arrays, memory consumption grows and end up with exception on Blazor, but not in WPF. Both are .NET 6.

[lambdageek]

In the sample _memoryUsed is populated by calling window.performance.memory.usedJSHeapSize in JS

I'm not sure if we shrink the .NET heap after we do a Mono GC and return that memory to JS. Assuming we don't, I wouldn't expect to see the JS heap size decrease after a mono collection. /cc @lewing