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

JIT: see if guarded devirtualization for EqualityComparer methods pays off #14223

AndyAyersMS opened this issue Sep 27, 2017 · 2 comments


Copy link

commented Sep 27, 2017

The changes for devirtualizing the EqualityComparer<T>.Default calls (#14125) don't kick in in cases where the user can optionally supply a custom comparer -- see for instance Dictionary<TKey, TValue> and many other generic collection types.

Since the jit can now determine the type of the default comparer, it might be worthwhile for the jit to insert a runtime test to see if a particular IEqualityComparer<T> typed object is actually the default comparer type for T, and if so, devirtualize and inline when the test succeeds.

I have a partial prototype of the changes needed here: master...AndyAyersMS:GuardedDevirtualization. This has most of the analysis needed to determine when the guarded devirtualization could be done cheaply enough that it is viable. However there are still some roadblocks to work out:

  • Marking the IEqualityComparer<T> methods as [Intrinsic] leads to odd errors in the runtime when generating marshalling stubs. Not clear yet what is going on. For now the prototype just checks all interface calls for this interface type, which is likely going to slow the jit down considerably.
  • The actual transformation can't be done in the current place(s) that impDevirtualizeCall is invoked, because the call may not yet be at top level. The rough idea here is to detect and defer this case, mark the original indirect call as an inline candidate, wait for it to get hoisted to top level, and then retry.


@AndyAyersMS AndyAyersMS added this to the Future milestone Sep 27, 2017
@AndyAyersMS AndyAyersMS referenced this issue Sep 27, 2017
5 of 23 tasks complete
@AndyAyersMS AndyAyersMS modified the milestones: Future, 2.1.0 Oct 27, 2017

This comment has been minimized.

Copy link
Member Author

commented Oct 27, 2017

Have some data that indicates that default comparers seem to predominate, so if we can speed them up a bit without slowing down the non-default comparers we may have something.

Considering this for 2.1.


This comment has been minimized.

Copy link
Member Author

commented Jan 18, 2018

Probably not getting to this in time for 2.1, so moving it back to Future.

@AndyAyersMS AndyAyersMS modified the milestones: 2.1.0, Future Jan 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.