-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Convert HELPER_METHOD_FRAME to QCalls (4/N) #95670
Conversation
LayoutDestroyNativeInternal
GetFunctionPointerForDelegateInternal
Jan - is there an issue/PR somewhere that explains the rationale behind these changes (perf, correctness, other?)? just curious! |
@dotnet-policy-service rerun |
@hughbe, perhaps there is no tracking issue, but I think this is a general goodness to have fewer FCalls as possible https://github.com/dotnet/runtime/blob/b345e2dbd6936eb281fadb7d70473358be578d24/docs/design/coreclr/botr/corelib.md#choosing-between-fcall-qcall-pinvoke-and-writing-in-managed-code. The ultimate goal is to gradually get rid of @jkotas, are we strictly converting FCalls to QCalls in this series, or to managed as well (when there is an opportunity)? |
Good point. I have opened #95695. It is something that myself, @AaronRobinsonMSFT, @davidwrighton discussed over lunch as a general goodness a few weeks ago. I have decided to work on it as my side-project. |
Yes, if there is an easy opportunity. There are a few cases like that in this PR:
|
This looks good although I might instead of converting the trailing byte code into a QCall instead produce a QCall/FCall that can produce the SyncBlock and then do the rest in managed. However, we could tackle that later. |
Yes, it is a trade-off in how many data type definition to mirror between managed and unmanaged sides. I have been leaning towards keeping this mirroring more minimal. |
No description provided.