Casting in a loop may cause long GC pause times

[jkotas]

dotnet/performance#1049 (comment)

[VSadov]

I think this is blocked on https://github.com/dotnet/coreclr/issues/27186 in a similar way as https://github.com/dotnet/coreclr/issues/27930 is.

[jkotas]

Casts are JIT helper calls. We do not have mechanism to mark JIT helper calls with SuppressGCTransitionAttribute today. We would need to add such mechanism.

I believe that the casts should be fixed by adding poll into the cast helpers. Or rewrite the hot path of the cast helpers in C# (like it is done in CoreRT), but that it harder to pull off.

[VSadov]

I think all JIT helpers can be treated as SuppressGCTransitionAttribute. At least for the purpose of adding polls when called from loops.

We control everything here. The number of FCALLs is very modest and we can assume/assure they are all well-behaving - either super fast or GC-polling.
I think whatever works for SuppressGCTransitionAttribute should be applicable to FCALL too.

[VSadov]

To not be distracted from general problem of FCALLs in a loop, which I think needs exactly the same solution as SuppressGCTransitionAttribute - I agree that making managed versions of fast path for casts would be a good idea.
I am not entirely sure how JIT would call that. As intrinsics? I think we should discuss that.

[jkotas]

I am not entirely sure how JIT would call that. As intrinsics? I think we should discuss that.

The JIT would call it exactly same as it does today. The VM would return the managed implementation when the JIT it asks for the entrypoint of the JIT helper.

[jkotas]

Fixed by #1068