-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Do not use RhGetCodeTarget
in delegate equality
#88611
Conversation
dotnet/corert@08d78ae The original motivation for this was handling import stubs: ``` Function pointer equality comparison was not handling cross-module pointers correctly when optimizations were enabled (causes target pointers to be wrapped in jump stubs sometimes). The delegate equality comparison was hitting this bug. ``` We do not have import stubs anymore and unwrapping unboxing stubs serves no purpose here. Microbenchmarks of delegate equality show ~3x improvement with this change: ``` Bench_DelegateEquality_Positive_OpenStatic<10000000>() took: 355 ms Bench_DelegateEquality_Positive_ClosedStatic<10000000>() took: 367 ms Bench_DelegateEquality_Positive_ClosedInstance<10000000>() took: 371 ms Bench_DelegateEquality_Positive_OpenStatic<10000000>() took: 121 ms Bench_DelegateEquality_Positive_ClosedStatic<10000000>() took: 120 ms Bench_DelegateEquality_Positive_ClosedInstance<10000000>() took: 122 ms ``` Additionally, there is some desire to upstream changes for a portable RhGetCodeTarget implementation. Not having to deal with it at this relatively low-level layer will make things more robust.
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsThe original motivation for this was handling import stubs:
We do not have import stubs anymore and unwrapping unboxing stubs serves no purpose here. Microbenchmarks of delegate equality show ~3x improvement with this change:
Additionally, there is some desire to upstream changes for a portable RhGetCodeTarget implementation. Not having to deal with it at this relatively low-level layer will make things more robust.
|
/azp run runtime-extra-platforms |
Azure Pipelines successfully started running 1 pipeline(s). |
Extra platform NAOT failures are all #88628, except for one
|
Which did not reproduce locally. Not clear what to do about it. |
I re-triggered the leg. I can't explain exit code 3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you!
dotnet/corert@08d78ae
The original motivation for this was handling import stubs:
We do not have import stubs anymore and unwrapping unboxing stubs serves no purpose here.
Microbenchmarks of delegate equality show ~3x improvement with this change:
Additionally, there is some desire to upstream changes for a portable RhGetCodeTarget implementation. Not having to deal with it at this relatively low-level layer will make things more robust.
Ref: dotnet/runtimelab#2333.