Convert all FCalls with HELPER_METHOD_FRAME to QCalls

[jkotas]

Benefits:

• Performance: QCalls are generally faster than FCalls with HELPER_METHOD_FRAME
• Eliminate duplication: These are redundant mechanism. Once all of them are converted, we can eliminate the duplication.
• Complexity of stackwalking algorithm: HELPER_METHOD_FRAMEs make the stackwalking algorithm with all its dependencies more complicated than it needs to be. (See nibblemapmacros do a linear scan #93550 for more context.)
  • We want to work towards unification of CoreCLR stackwalker and native AOT stackwalker. Native AOT has much simpler stackwalker and it does not have HELPER_METHOD_FRAMEs.

[hughbe]

This is cool! Is the plan to eventually remove FCall functionality from the runtime?

[danmoseley]

Good to see you around here again @hughbe! 😀

[jkotas]

Is the plan to eventually remove FCall functionality from the runtime?

FCalls with HELPER_METHOD_FRAME. I think FCalls without HELPER_METHOD_FRAME are needed for perf reasons.

[davidwrighton]

I think we also might be able to move to QCalls with SuppressGCTransition instead of FCalls without HELPER_METHOD_FRAME for the perf critical ones, but that's a bridge to examine and consider crossing once we've removed HELPER_METHOD_FRAME from the situation.

[jkotas]

I think we also might be able to move to QCalls with SuppressGCTransition instead of FCalls without HELPER_METHOD_FRAME for the perf critical ones, but that's a bridge to examine and consider crossing once we've removed HELPER_METHOD_FRAME from the situation.

I agree. It would require modifying rules for how GC tracked pointers are passed to and from P/Invokes and we would need to deal with managed/unmanaged calling convention differences somehow. I think it would be just a cosmetic change at the end. It would not be a significant simplification of the system (compared to getting rid of HELPER_METHOD_FRAMEs).

[huoyaoyuan]

I believe this was closed unintentionally 😄

In addition, I'd like to see some documentation about the more and more unmanaged-like unsafe code in CoreLib. I'm still learning and trying case by case.

[jkotas]

I'd like to see some documentation about the more and more unmanaged-like unsafe code in CoreLib.

What would you like to see? The documentation about QCalls and related topics is in https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/corelib.md .

[huoyaoyuan]

The existing documentation is about "manual managed" code. Nowadays there are more "manual unmanaged" code in CoreLib, for example, dealing with MethodTable and manipulating GC refs as bytes.

[jkotas]

Feel free to propose documentation update in a PR.

The examples do not look unique to CoreLib. MethodTable is an example of an unmanaged resource with lifetime associated with managed object. These situations occur in interop quite frequently. GC.KeepAlive documentation has an example with COM.