Error out when struct size is bigger than int.MaxValue

[fanyang-mono]

Fixes: #97412

sizeof() in C# returns a signed integer. This PR is to adjust the runtime to match with that.

Added a check for struct size and a test.

[jkotas]

Do we need a test?

[fanyang-mono]

@jkotas This PR is ready to be reviewed again.

[MichalStrehovsky]

I've pushed out a change that makes further progress in the handling within the managed type system, but the test probably still won't compile because BigArray with size of int.MaxValue gets its size bumped past int.MaxValue through alignment after we're done with layout (the final size needs to be divisible by pointer size and int.MaxValue isn't.

CoreCLR is fine with this overflowing but the managed type system isn't. I'm not sure if the overflow is an actual problem but fixing it doesn't look exactly trivial.

[fanyang-mono]

@MichalStrehovsky Is there a way to stop the new test from being compiled by NativeAOT?

[MichalStrehovsky]

@MichalStrehovsky Is there a way to stop the new test from being compiled by NativeAOT?

Only by placing <NativeAotIncompatible>true</NativeAotIncomplatible> in the project file. It would be good not to disable all existing ManagedSequential type loader testing just because the new test doesn't work (i.e. put it in a separate project file).

Note that this is the managed type system that is shared with crossgen2. Might want to run crossgen2 outerloop testing to see whether this also needs to be removed from precompilation there.

The managed type system doesn't handle this test because the size of the BigArray struct is actually over 2 GB when boxed (this is also true on JIT-based CoreCLR). If a 2 GB overflow is problematic, is the 2 GB overflow of that one not problematic?

[fanyang-mono]

@MichalStrehovsky Based on Jan's comment from earlier. Loading BigArray itself should continue to work. Why do we need to align BigArray to pointer size? If that's needed, sizeof(BigArray) would return a bigger value than int.MaxValue. Is that correct?

[MichalStrehovsky]

@MichalStrehovsky Based on Jan's comment from earlier. Loading BigArray itself should continue to work. Why do we need to align BigArray to pointer size? If that's needed, sizeof(BigArray) would return a bigger value than int.MaxValue. Is that correct?

The size of it gets aligned when boxing it, because it's 8 bytes larger (MethodTable pointer) and aligned. On CoreCLR today, doing:

BigArray.Instance = new BigArray();

long before = GC.GetAllocatedBytesForCurrentThread();
BigArray.Instance = new BigArray();
Console.WriteLine(GC.GetAllocatedBytesForCurrentThread() - before);

[StructLayout(LayoutKind.Sequential, Size = int.MaxValue)]
struct BigArray
{
    public static object Instance;
}

Will print 2,147,483,664, which is larger than int.MaxValue.

[fanyang-mono]

/azp list

[azure-pipelines]

CI/CD Pipelines for this repository:

• runtime-coreclr outerloop
• runtime-coreclr jitstress
• runtime-coreclr jitstressregs
• runtime-coreclr jitstress2-jitstressregs
• runtime-coreclr gcstress0x3-gcstress0xc
• runtime-coreclr gcstress-extra
• runtime-coreclr r2r-extra
• runtime-coreclr jitstress-isas-x86
• runtime-coreclr jitstress-isas-arm
• runtime-coreclr jitstressregs-x86
• runtime-coreclr libraries-jitstressregs
• runtime-coreclr libraries-jitstress2-jitstressregs
• runtime-coreclr r2r
• runtime-coreclr runincontext
• runtime-coreclr crossgen2
• runtime-libraries-coreclr outerloop
• runtime-libraries-coreclr outerloop-windows
• runtime-libraries-coreclr outerloop-linux
• runtime-libraries-coreclr outerloop-osx
• runtime
• runtime-libraries enterprise-linux
• runtime-libraries stress-http
• runtime-libraries stress-ssl
• runtime-dev-innerloop
• runtime-coreclr crossgen2 outerloop
• coreclr-release-outerloop-nightly
• runtime-coreclr crossgen2-composite
• runtime-jit-experimental
• runtime-coreclr libraries-jitstress
• dotnet-linker-tests
• runtime-coreclr ilasm
• runtime-coreclr crossgen2-composite gcstress
• runtime-staging
• runtime-coreclr pgo
• runtime-coreclr libraries-pgo
• Antigen
• runtime-community
• Fuzzlyn
• runtime-coreclr superpmi-replay
• runtime-wasm
• runtime-coreclr superpmi-diffs
• runtime-coreclr superpmi-asmdiffs-checked-release
• runtime-extra-platforms
• jit-cfg
• runtime-wasm-perf
• runtime-llvm
• runtime-coreclr jitstress-random
• runtime-coreclr libraries-jitstress-random
• runtime-android-grpc-client-tests
• runtime-wasm-non-libtests
• runtime-android
• runtime-androidemulator
• runtime-ioslike
• runtime-ioslikesimulator
• runtime-linuxbionic
• runtime-maccatalyst
• runtime-coreclr pgostress
• runtime-coreclr jitstress-isas-avx512
• runtime-libraries-mono outerloop
• runtime-sanitized
• runtime-wasm-dbgtests
• runtime-wasm-optional
• runtime-nativeaot-outerloop

[MichalStrehovsky]

The size of it gets aligned when boxing it, because it's 8 bytes larger (MethodTable pointer) and aligned. On CoreCLR today, doing:

We chatted with Fan on Teams about this and apparently the program I posted only works on a Release build (also without debugger attached) and throws InvalidProgram otherwise. On .NET 8 CoreCLR-JIT. Curious.

[fanyang-mono]

@MichalStrehovsky CoreCLR and Mono side of work has been completed and approved. The remaining piece of work is related to NativeAOT/Crossgen2. I am going to transfer the ownership of this PR to you, since you will be working on that.

Additionally, this could probably be merged for .NET9, as I don't think that this is a breaking change. @jkotas Please correct me, if I were wrong.

[MichalStrehovsky]

The remaining piece of work is related to NativeAOT/Crossgen2. I am going to transfer the ownership of this PR to you, since you will be working on that.

I'll not have time to look at this any time soon. Might be better to just block the test on an issue and not block this PR.

Additionally, this could probably be merged for .NET9, as I don't think that this is a breaking change.

Throwing an exception in a situation that didn't throw before is the definition of a breaking change.

[fanyang-mono]

Discussed with @jkotas offline. He suggested to wait for .NET10 to merge it, together with the NativeAOT change, when it is ready.

There is no rush. @MichalStrehovsky

[fanyang-mono]

I plan to merge this PR when main is .NET10. The managed type system part used by NativeAOT and crossgen can be worked on later during .NET10 release.

[fanyang-mono]

/azp run runtime-coreclr crossgen2

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[fanyang-mono]

/azp run runtime-coreclr crossgen2

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[fanyang-mono]

/azp run runtime-coreclr crossgen2

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[fanyang-mono]

CI failures are unrelated to this PR.