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

Adding Int128 and UInt128 with a base software implementation #69204

Merged
merged 20 commits into from
May 19, 2022

Conversation

tannergooding
Copy link
Member

This does not cover acceleration in the JIT, that will be a separate work item and will be handled in a follow up PR.

@dotnet-issue-labeler
Copy link

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@ghost
Copy link

ghost commented May 11, 2022

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

Issue Details

This does not cover acceleration in the JIT, that will be a separate work item and will be handled in a follow up PR.

Author: tannergooding
Assignees: tannergooding
Labels:

area-System.Numerics, new-api-needs-documentation

Milestone: -


if ((strcmp(name, g_Int128Name) == 0) || (strcmp(name, g_UInt128Name) == 0))
{
pLayout->m_ManagedLargestAlignmentRequirementOfAllMembers = 16; // sizeof(__int128)
Copy link
Member

Choose a reason for hiding this comment

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

This needs equivalent fix in crossgen/NativeAOT and in Mono

Copy link
Member Author

Choose a reason for hiding this comment

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

@fanyang-mono could you point me to where Mono handles custom struct packing/alignment?

I tried checking for where that's handled for the vector types, but couldn't find it.

Int128 and UInt128 need to have 16-byte packing when targeting the System V ABI (used by Unix) and the same packing/alignment as Int64/UInt64 otherwise (such as on Windows or 32-bit platforms).

Copy link
Member Author

Choose a reason for hiding this comment

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

-- I fixed this up for crossgen/NativeAOT already and added corresponding P/Invoke tests to ensure the data is passed correctly to/from Native.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's handled in mono_class_layout_fields () in metadata/class-init.c.
Not sure the mono gc supports 16 byte aligned objects on 32 bit platforms.

Copy link
Member Author

Choose a reason for hiding this comment

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

This doesn't impact 32-bit platforms, only 64-bit platforms (and only 64-bit Unix at that).

Copy link
Member Author

Choose a reason for hiding this comment

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

@vargaz, looks like its just blocked everywhere not just 32-bit platforms: https://github.com/dotnet/runtime/blob/main/src/mono/mono/metadata/class-init.c#L2058-L2065

It looks like Mono also isn't differentiating "alignment" from "packing" and so the layout of types that include the new Int128, UInt128, or the existing Vector64<T>, Vector128<T>, Vector256<T> types will be incorrect.

This would explain why I couldn't find any logic touching Vector128<T> and ensuring that it has the right packing (and therefore layout) even if the GC couldn't correctly align the overall allocation.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, it looks like this is not implemented right now in mono.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'll log an issue to ensure this is tracked (I don't see an existing issue).

Copy link
Member Author

Choose a reason for hiding this comment

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

Logged #69399

@tannergooding
Copy link
Member Author

Hmmm. Tests were all passing locally but failing in CI, going to need to investigate this more

@tannergooding
Copy link
Member Author

This should just need the NativeAOT and Mono fixups to ensure Int128 and UInt128 are Pack = 16 on Sys V (x64 and Arm64)

@tannergooding
Copy link
Member Author

tannergooding commented May 13, 2022

I also apparently forgot to implement conversions to and from float/double/decimal, so I will do that and add tests. Marking as NO-MERGE in the meantime

@tannergooding tannergooding added the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 13, 2022
@tannergooding tannergooding removed the NO-MERGE The PR is not ready for merge yet (see discussion for detailed reasons) label May 13, 2022
Copy link
Contributor

@deeprobin deeprobin left a comment

Choose a reason for hiding this comment

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

Have noted a few minor things.
But looks very good.

Looking forward to Int128 and UInt128 🎉😄.

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jkotas
Copy link
Member

jkotas commented May 18, 2022

ibraries Test Run checked coreclr Linux arm Debug
ibraries Test Run checked coreclr Linux_musl arm64 Debug

Both these runs failed with GC asserts. I do not think we have any issues tracking failures like this. Is it caused by the changes in this PR?

@tannergooding
Copy link
Member Author

Both these runs failed with GC asserts. I do not think we have any issues tracking failures like this. Is it caused by the changes in this PR?

I'll take a look but I find it doubtful that it'd be caused by this PR. It wasn't failing before and the only change since the last run was to update the native layout for Int128/UInt128. Neither of these types are used by the Regex or Http tests.

Http is failing BOOL MethodTable::SanityCheck() for:

    // strings have component size2, all other non-arrays should have 0
    _ASSERTE((GetComponentSize() <= 2) || IsArray());

The other (Regex) is failing _ASSERTE(RawGetMethodTable()) in void CObjectHeader::SetMarked()

Copy link
Contributor

@dakersnar dakersnar left a comment

Choose a reason for hiding this comment

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

Changes look good, thanks!

@jkotas
Copy link
Member

jkotas commented May 18, 2022

Neither of these types are used by the Regex or Http tests.

These asserts are generic signs of GC heap corruption. A bug introduced in common parts (e.g. parsing/formatting) can lead to intermittent crash like that.

@tannergooding
Copy link
Member Author

tannergooding commented May 18, 2022

These asserts are generic signs of GC heap corruption. A bug introduced in common parts (e.g. parsing/formatting) can lead to intermittent crash like that.

I'd speculate there may be another issue with Unsafe.As then and there is still something wrong with 7666952

There was a similar issue exposed by making Unsafe.As "intrinsic" that was fixed in #69271 and its possible this is another case that hasn't been found yet.

@tannergooding
Copy link
Member Author

It could be related to #69501 for example, which @SingleAccretion just opened and impacts structs.

@tannergooding
Copy link
Member Author

If this one is also related to Unsafe.As, then it may be worth reverting just that one from intrinsic handling for the time being, as this will have been the 3rd (iirc) GC related issue it exposed.

@tannergooding
Copy link
Member Author

I'm not 100% this fixes the issue as its not a reliable repro. But I did hit it in 20 runs with the Unsafe.As usage and didn't hit it in 40 without it removed.

@jkotas
Copy link
Member

jkotas commented May 18, 2022

/azp run runtime-extra-platforms

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jakobbotsch
Copy link
Member

I'm not 100% this fixes the issue as its not a reliable repro. But I did hit it in 20 runs with the Unsafe.As usage and didn't hit it in 40 without it removed.

Can you give instructions for how to repro this? If we have a repro for it we need to look at it, it could be manifesting in other places that are way harder to diagnose.

@tannergooding
Copy link
Member Author

Can you give instructions for how to repro this? If we have a repro for it we need to look at it, it could be manifesting in other places that are way harder to diagnose.

It was just running the Int128/UInt128 tests with and without the Unsafe.As. I imagine it would reproduce for any non-primitive struct.

@jkotas
Copy link
Member

jkotas commented May 18, 2022

The new Int128 PInvoke test is failing on Android in the extra platforms leg.

@tannergooding
Copy link
Member Author

Looks like it can't resolve the native library: System.DllNotFoundException: Int128Native

@vargaz is there anything additional required for P/Invoke to work on Android? Does the library have or need some special name that differs from the default for example?

@tannergooding
Copy link
Member Author

The tvOS and iOS failures look unrelated, they seem to have just failed and look to be doing that in other jobs as well.

@tannergooding
Copy link
Member Author

Hmmm, it looks like most of the Interop/PInvoke/* tests are currently disabled on Mono. See https://github.com/dotnet/runtime/blob/main/src/tests/issues.targets#L1716-L1772 under https://github.com/dotnet/runtime/blob/main/src/tests/issues.targets#L1446-L1447; and more further down and in other mono areas.

Most are marked "needs triage" as well.

@tannergooding
Copy link
Member Author

tannergooding commented May 19, 2022

There are various other extra-platforms failures but the android issue is the only one that looks related. Others look to be failures more broadly impacting these jobs in particular, many of them are just general timeouts at 240 minutes.

Given the breadth of P/Invoke tests disabled for Android, I'd be inclined to log an issue tracking Mono enabling interop here. The alternative would be to just block Int128/UInt128 from all interop until Mono can add support. The tests likely need to be disabled on mono regardless given that the native library isn't resolving.

@jkotas
Copy link
Member

jkotas commented May 19, 2022

Disabling the interop test on Android should be fine.

@tannergooding
Copy link
Member Author

tannergooding commented May 19, 2022

Logged #69531.

Noting I grouped this with the other Mono P/Invoke disablement as tvOS and iOS didn't actually run the tests, they hit the more general timeout issue.

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.

None yet

7 participants