Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 20 commits into from
Apr 10, 2024

Conversation

EgorBo
Copy link
Member

@EgorBo EgorBo commented Mar 26, 2024

Fixes #100220

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

@EgorBo
Copy link
Member Author

EgorBo commented Apr 6, 2024

/azp list

This comment was marked as resolved.

@EgorBo
Copy link
Member Author

EgorBo commented Apr 6, 2024

/azp run runtime-nativeaot-outerloop

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@EgorBo
Copy link
Member Author

EgorBo commented Apr 7, 2024

/azp run runtime-nativeaot-outerloop

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@EgorBo
Copy link
Member Author

EgorBo commented Apr 7, 2024

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

@EgorBo EgorBo marked this pull request as ready for review April 7, 2024 12:08
@jkotas
Copy link
Member

jkotas commented Apr 7, 2024

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.

}

[MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)]
private static int GetManagedSize(Func<object> allocator)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

@MichalPetryka MichalPetryka Apr 7, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Invoked GetRawObjectDataSize via reflection

@jkotas
Copy link
Member

jkotas commented Apr 7, 2024

/azp run runtime-coreclr r2r

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

// Also, Mono needs RuntimeHelpers.GetRawObjectDataSize or equivalent to get an object size
public static int TestEntryPoint()
{
if (IntPtr.Size == 8)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@EgorBo EgorBo Apr 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@EgorBo
Copy link
Member Author

EgorBo commented Apr 8, 2024

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

@lewing
Copy link
Member

lewing commented Apr 9, 2024

The maui team is waiting for a resolution on this

@EgorBo
Copy link
Member Author

EgorBo commented Apr 9, 2024

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

@MichalStrehovsky
Copy link
Member

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.

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you for adding a lot of tests!

@EgorBo
Copy link
Member Author

EgorBo commented Apr 10, 2024

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?

@EgorBo EgorBo merged commit 4d5e5ff into dotnet:main Apr 10, 2024
96 checks passed
tomeksowi added a commit to tomeksowi/runtime that referenced this pull request Apr 11, 2024
Test introduced in dotnet#100289 failed the build of CLR tests for e.g. RISC-V:
```
/runtime/src/tests/Loader/classloader/explicitlayout/Regressions/100220/Runtime_100220.cs(15,23): error XUW1002: Tests should not unconditionally return 100. Convert to a void return.
```
jakobbotsch pushed a commit that referenced this pull request Apr 11, 2024
Test introduced in #100289 failed the build of CLR tests for e.g. RISC-V:
```
/runtime/src/tests/Loader/classloader/explicitlayout/Regressions/100220/Runtime_100220.cs(15,23): error XUW1002: Tests should not unconditionally return 100. Convert to a void return.
```
matouskozak pushed a commit to matouskozak/runtime that referenced this pull request Apr 30, 2024
matouskozak pushed a commit to matouskozak/runtime that referenced this pull request Apr 30, 2024
Test introduced in dotnet#100289 failed the build of CLR tests for e.g. RISC-V:
```
/runtime/src/tests/Loader/classloader/explicitlayout/Regressions/100220/Runtime_100220.cs(15,23): error XUW1002: Tests should not unconditionally return 100. Convert to a void return.
```
@github-actions github-actions bot locked and limited conversation to collaborators May 12, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Non-blittable struct with explicit layout has wrong managed size
6 participants