Can we use EmccMaximumHeapSize to change the maximum size of the heap to 4gb?

[dlemstra]

I am working on a project that uses Blazor and can use a lot of memory. We would love to have Memory64 support as mentioned in #94108 but for now we are limited to increasing the size of the heap from 2gb to 4gb. But it looks like this is not fully supported? When I enable this in our project I get out of bounds errors that look like an int overflow:

MONO_WASM: jit_call code generation failed: RangeError: Start offset -2038988752 is outside the bounds of the buffer
MONO_WASM: // 1 jit call wrappers generated, blob follows //
MONO_WASM: // #0 === jcp_419b4_0 hasThis=true hasRet=true wasmArgTypes=127,127,127

Assert failed: Overflow: value -956889432 is out of 0 4294967295 range dotnet.native.8.0.2.6av86pdsis.js:8 
Error: Assert failed: Overflow: value -956643752 is out of 0 4294967295 range

Should we be able to use <EmccMaximumHeapSize>4294901760</EmccMaximumHeapSize> to increase the size of the heap or should we not do this? I have created a discussion instead of an issue because I cannot create a small project that reproduces this. It looks like jit_call is part of the Jiterpreter. Is there an option to disable this so we can check if increasing the heap size only causes issues in the Jiterpreter?

[maraf]

You can disable jiterpreter with <BlazorWebAssemblyJiterpreter>false</BlazorWebAssemblyJiterpreter>.
You are using the EmccMaximumHeapSize correctly, I just need to check the max value, because I'm not sure if it can be "all memory" or whether it needs to substract stack size (it is directly passed to emscripten as MAXIMUM_MEMORY and according to their setting it to 4gb should be ok)

[lewing]

@dlemstra can you give me the exact stack when you see an error? Have you tried testing against a .NET 9 preview? The assertion you are hitting is likely in code that has changed substantially in .NET 9 and without more ether more details about the error or a way to reproduce the problem it will be challenging to validate any fix.

[dlemstra]

The stack trace that we have doesn't give a lot of information but I do have some screenshots from last time here: exceptions.zip

We have not yet tested this with the .NET 9 preview. I also some some changes merged in the related issue. Are those changes already available in .NET 9 preview? We have not been able to create something small that reproduces this issue. I suspect we are doing something in our application that triggers this or the size of our application makes this more likely to happen.

[pavelsavara]

@dlemstra would you be interested to have Teams call with me to discuss the problems ?

[dlemstra]

Of course. Feel free to email me or reach out on teams in the MS tenant.

[pavelsavara]

sent you email to your lemstra.org address, please let me know if that's good time. We are both in Europe.

[Matheos96]

Hello, Any update/answer to this? I am interested in knowing this as well... I tried to set

<EmccMaximumHeapSize>4294901760</EmccMaximumHeapSize>
      <BlazorWebAssemblyJiterpreter>false</BlazorWebAssemblyJiterpreter>
      <EmccInitialHeapSize>3145728</EmccInitialHeapSize>

in our Blazor WASM (standalone) .NET 8 application but it made no difference. I have some simple .NET code that allocates memory in 1MB chunks until it gets an OOM exception. This reliably always happens at 1767MB (in my case) - that is ".NET memory". The JS heap size is then 2165MB and never the expected 4GB. Not even the initial heap size I tried above seem to have any effect