Align up structs to IntPtr.Size if they have gc pointers

[EgorBo]

Fixes #100220

I am not an expert in R2R/NAOT type system, but looks like it fixes the issue

[EgorBo]

/azp list

[EgorBo]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[EgorBo]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[EgorBo]

Probably needs #100618 since the GC.* trick is not reliable to get object size in tests.

Otherwise should be ready. The rules turn out to be a bit complex, e.g.

[StructLayout(LayoutKind.Sequential, Size = 1000)]
class ClassA
{
    long A;
}

[StructLayout(LayoutKind.Explicit, Size = 1000)]
class ClassB
{
    [FieldOffset(0)]
    long A;
}

Here, CoreCLR allocates 1016 bytes for an instance of ClassA and 24 bytes for ClassB - I am not sure whether it should be "fixed" in CoreCLR, but I aligned NAOT/R2R, so the rules are:

• Classes:
  • Layout has gc pointers - we ignore explicit Size
  • LayoutKind.Explicit - we ignore explicit Size (bug-to-bug compat?)
• Structs:
  • LayoutKind.Sequential + gc pointers - we ignore explicit Size
  • Layout has gc pointers - we align up size to target pointer

So for classes, the only case when we respect Size is LayoutKind.Sequential + no gc pointers.

Questionable behavior in CoreCLR (Main) for (boxed) object size:

1. For a class without gc refs, why do we ignore Size= for LayoutKind.Explicit, but not for LayoutKind.Sequential?
2. For a struct with gc ref(s), should we ignore Size= for even LayoutKind.Explicit ? (we do for LayoutKind.Sequential). Since gc references can easily "invalidate" explicit Size by AlignUp(8).

cc @jkotas

[jkotas]

Probably needs #100618 since the GC.* trick is not reliable to get object size in tests.

I do not think it would help you. This API gives you the exact same result as sizeof.

[jkotas]

This is not reliable as you have pointed out.

I think a reliable version of this check would be to inherit from the type you want to check, add a byte field, and verify offset of the byte field.

[MichalPetryka]

Would an UnsafeAccessor to RuntimeHelpers.GetRawObjectDataSize work better here instead maybe?
EDIT: Ah wait, that's a static class, nevermind.

[EgorBo]

Invoked GetRawObjectDataSize via reflection

[jkotas]

/azp run runtime-coreclr r2r

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MichalPetryka]

Should this maybe not have the if and multiply the pointer size appropriately in each case?

[EgorBo]

I prefer expected value to be a constant rather than computed expression for Asserts

[EgorBo]

@jkotas anything else here? looks like R2R and NAOT outerloops passed

[lewing]

The maui team is waiting for a resolution on this

[EgorBo]

I assume Jan is OOF, so maybe @MichalStrehovsky can review this?

[MichalStrehovsky]

I assume Jan is OOF, so maybe @MichalStrehovsky can review this?

There is a reason I moved this to crossgen2 team (#100220 (comment)). Type layout needs to exactly match CoreCLR type layout for ReadyToRun to work. It has been a bug farm in the past. I don't see anything obviously wrong in this PR but that's not a high quality bar. I know we have modes of operation of crossgen2 where it serializes type layout into the image and validates it at runtime, but I don't know what CI legs that runs in and if this would cover it too. Can you get @davidwrighton to have a look? I really only have surface-level knowledge of R2R testing and very much hope I'm not the biggest expert.

[jkotas]

LGTM. Thank you for adding a lot of tests!

[EgorBo]

The maui team is waiting for a resolution on this

@lewing do we need to backport the fix to a specific release preview branch? if so, which?