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.

Work

List of JIT helpers that need the removal of explicit HMFs:

• JIT_GetFieldAddr_Framed
• JIT_New
• JIT_NewMaybeFrozen
• FramedAllocateString
• JIT_StrCns
• JIT_NewArr1
• JIT_NewArr1MaybeFrozen
• JIT_NewMDArr
• JIT_Box
• JIT_GetRuntimeFieldStub
• JIT_GetRuntimeMethodStub
• JIT_GetRuntimeType_Framed
• JIT_MonEnter_Helper
• JIT_MonTryEnter_Helper
• JIT_MonExit_Helper
• JIT_MonExit_Signal
• IL_Throw
• IL_Rethrow
• JIT_ThrowMethodAccessException
• JIT_ThrowFieldAccessException
• JIT_ThrowClassAccessException
• JIT_UserBreakpoint
• JIT_PollGC_Framed
• JIT_PInvokeEndRarePath
• JIT_RareDisableHelper/JIT_RareDisableHelperWorker
• JIT_StressGC
• JIT_Patchpoint_Framed
• JIT_PartialCompilationPatchpoint

List of JIT helpers with implicit HMFs through a use of FCThrow.

• JIT_Div, JIT_Mod, JIT_UDiv, JIT_UMod, JIT_LDiv, JIT_LMod, JIT_ULDiv, JIT_ULMod - Move arithmetic helpers to managed code #109087

The following clean-up can occur after all the above is complete:

• Removal of fcall.h and fcall.cpp
• Update BoTR to remove description of FCalls.

[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.

[AaronRobinsonMSFT]

Below is a list of various PRs that can be referenced that demonstrate this effort across multiple authors and releases.

#70000, #70055, #71873, #87166, #95038, #96926, #97590, #100116, #101353, #106793, #107058, #107218, #107648, #108167, #109135, #109996, #110064, #110211, #110377, #110481, #110627, #110766

[AaronRobinsonMSFT]

See #110767 for some additional context/notes.

[AaronRobinsonMSFT]

From: #110767 (comment)

The way @VSadov consolidated lock primitives with NativeAOT, if we continue on that path, maybe it is possible to share the entire implementation with AOT (which has this HCall written in C#).

@am11 Agree. The goal for any converted HCalls, likely needed in assembly, is that they could be shared with native AOT.

There is also a related JIT_Patchpoint HCall, which ends up using VirtualUnwindToFirstManagedCallFrame, not sure if there is a better structured way to tackle it without the libunwind dependency but would be nice to switch to one if it exists.

Yep, the JIT_Patchpoint calls JIT_Patchpoint_Framed. This is a common pattern when an FCall/HCall was frameless and then it needs one to perform a throwable or GC action, a new function was written with the _Framed or _Helper suffix and called.