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.

Sign up for GitHub

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

Jump to bottom

Casting in a loop may cause long GC pause times #13821

Closed
jkotas opened this issue Nov 23, 2019 · 6 comments
Closed

Casting in a loop may cause long GC pause times #13821

jkotas opened this issue Nov 23, 2019 · 6 comments
Assignees
@VSadov
Labels
area-VM-coreclr tenet-performance Performance related issue

Comments

@jkotas
Copy link
Member

jkotas commented Nov 23, 2019

dotnet/performance#1049 (comment)
@VSadov
Copy link
Member

VSadov commented Nov 24, 2019

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
Copy link
Member Author

jkotas commented Nov 24, 2019

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
Copy link
Member

VSadov commented Nov 24, 2019

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
Copy link
Member

VSadov commented Nov 24, 2019

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
Copy link
Member Author

jkotas commented Nov 24, 2019

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.

@VSadov VSadov self-assigned this Dec 11, 2019
VSadov referenced this issue Jan 22, 2020
@VSadov
Moving fast parts of cast FCALLs to managed code. (#1068)
c3dc1fd 
* Exposed casting cache to managed code
* Implemented a managed version of cache lookup
* Moved `JIT_IsInstanceOfAny` and `JIT_ChkCastAny`  to managed code as the first ones to move.
* Skip managed JIT helpers in exception stack traces and debugger
* Managed `JIT_IsInstanceOfInterface`
* All other cast helpers are managed.

Fixes:https://github.com/dotnet/coreclr/issues/27931
@jkotas
Copy link
Member Author

jkotas commented Jan 28, 2020

Fixed by #1068

@jkotas jkotas closed this as completed Jan 28, 2020
@msftgits msftgits transferred this issue from dotnet/coreclr Jan 31, 2020
@richlander richlander mentioned this issue Jun 6, 2020
Closed
@ghost ghost locked as resolved and limited conversation to collaborators Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@VSadov VSadov

Labels
area-VM-coreclr tenet-performance Performance related issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@jkotas @VSadov