-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Struct interface dispatch still allocating for ref generics #9947
Comments
There is a chain of optimizations required here and the jit hits a limitation at the last step.
To get rid of the box we need the full chain to fire. I don't recall offhand why the jit didn't or couldn't handle the case where the unboxed entry needs an extra argument. Let me dig in some more. |
Thanks for looking into it... |
Looks like a problem with inlining of dictionary access. The current JIT/EE interface contract is not designed to track enough type information details to inline dictionary access. It may be possible to fix this if the chain originates from non-generic code. But once you start calling it from generic code and change |
We don't have to make it all the way to inlining here -- if we can rework the call to invoke the unboxed entry point we can remove the upstream allocation. I have a prototype that seems to be working...let me test it a bit more. Assumption here is that whatever value the jit was going to pass to the newobj helper is the right value to pass as the context arg to the unboxed entry point (in other words in the unboxing stub that we'd normally call, the context always comes from the |
Improve the jit's ability to optimize a box-interface call sequence to handle cases where the unboxed entry point requires a method table argument. Added two test cases, one from the inspiring issue, and another where the jit is then able to inline the method. Closes #16982.
Improve the jit's ability to optimize a box-interface call sequence to handle cases where the unboxed entry point requires a method table argument. Added two test cases, one from the inspiring issue, and another where the jit is then able to inline the method. Closes #16982.
Improve the jit's ability to optimize a box-interface call sequence to handle cases where the unboxed entry point requires a method table argument. Added two test cases, one from the inspiring issue, and another where the jit is then able to inline the method. Closes #16982.
dotnet/coreclr#14698 helped to avoid allocations when invoking methods on structs cast to interfaces, but it appears it didn't completely address it.
This code:
https://github.com/dotnet/coreclr/blob/8758f76b4e5ba6733e4f3184293414fc9182d06f/src/mscorlib/src/System/Runtime/CompilerServices/AsyncMethodBuilder.cs#L392-L398
takes advantage of this feature, and with a repro like:
it successfully avoids the allocation, but change the
int
s in the above tostring
s, and it starts allocating boxes for the interface:@AndyAyersMS, could you take a look?
We either need to fix this for 2.1 (if you can that would be excellent), or in 2.1 I need to change the async method builder code to work a different way, as we can't have this allocation happening per await.
The text was updated successfully, but these errors were encountered: