Share allocation helpers between CoreCLR and NativeAOT

[filipnavara]

Share assembly version of allocation helpers between CoreCLR and NativeAOT. This allows better code reuse and removes the last usage of helper method frames in the CoreCLR runtime, cleanup is expected to be done separetely.

The slow paths on CoreCLR differ from NativeAOT in few details. They don't expect the GC_ALLOC_FINALIZE, GC_ALLOC_ALIGN8 and GC_ALLOC_ALIGN8_BIAS flags to be passed the correct values and if they are not present then they get inferred from the method table. This means that helpers like RhpNewFinalizable stay exclusive to NativeAOT and remain unused on CoreCLR. This is done intentionally so we can have a single slow path (RhpNew for objects, RhpNewArray for arrays) that can be assigned to any JIT helper. The slow path is used when allocation tracking is enabled or for other diagnostic options.

CoreCLR stores the per-thread allocation context in separate TLS variable, while NativeAOT track it as part of the main per-thread information. We abstract it by introducing INLINE_GET_ALLOC_CONTEXT macro that returns the pointer to ee_alloc_context structure.

FastAllocateString helper in CoreCLR has a changed signature to take the string method table as the first parameter. This mimics the same idea as used by NativeAOT where we can use slow array allocation helper and fast string allocation helper interchangably.

Platform specific notes:

• linux-x86 didn't have the helpers implemented; the implementation is added and passed some smoke tests.
• linux-riscv64 implementation was heavily rewritten. The main change is to establish function frame and move arguments into non-volatile registers. We support platform versions without TLS descriptor and this ensures that we only save minimum number of registers to stack to enable INLINE_GET_ALLOC_CONTEXT doing function call that trashes volatile registers.
• linux-arm helpers for Align8/Misalign cases were enhanced to include padding with "free object" in the fast path.

Contributes to #95695

[filipnavara]

@jkotas I'd appreciate if you could take a look, only the second commit onwards (f3b968c as of this writing). Just want some opinion to avoid veering off in a completely wrong direction and wasting time on it. No need to do some in-depth review, there are still lots of things to clean up.

[jkotas]

The general shape LGTM. Thank you!

[filipnavara]

This is now ready for some initial review pass.

[filipnavara]

cc @tomeksowi can we run the RISC-V bot on this?
cc @LuckyXu-HF any change you could test the LA64 changes?

[LuckyXu-HF]

cc @LuckyXu-HF any change you could test the LA64 changes?

Of course. It will take some time to fully build the NativeAOT testcases, so the results will come out later.
cc @shushanhf @Jabyn1031

[am11]

Smoke tests passed with 3ac08ee.

freebsd-x64: https://github.com/am11/CrossRepoCITesting/actions/runs/15390897782
freebsd-arm64: https://github.com/am11/CrossRepoCITesting/actions/runs/15390894162
linux-riscv64: https://github.com/am11/CrossRepoCITesting/actions/runs/15390908161
linux-musl-riscv64: https://github.com/am11/CrossRepoCITesting/actions/runs/15390903304
linux-loongarch64: https://github.com/am11/CrossRepoCITesting/actions/runs/15390915142
linux-musl-loongarch64: https://github.com/am11/CrossRepoCITesting/actions/runs/15390919020

[filipnavara]

Smoke tests passed with 3ac08ee.

Thanks for testing! I run it locally before pushing it but this is more comprehensive check.

[jkotas]

LGTM otherwise!

[jkotas]

The implementation of RhpNewVariableSizeObject does not expect the extra flags argument.

• On x86, it is going to result into stack imbalance
• On arm, we do not pass the flags through, so it is not going to allocate 8-byte aligned array when needed

I think we may want to replace the calls to this with calls to RhAllocateNewArray instead.

[filipnavara]

Good catch, probably worth re-running /azp run runtime-nativeaot-outerloop.

[filipnavara]

I changed it to use RhAllocateNewArray. Alternative was to change to (misnamed) RhpNewArrayFastAlign8 / RhpNewVariableSizeObject with no flags parameter. Then again, it is a code path slated for a cleanup in the follow-up.

[MichalStrehovsky]

/azp run runtime-nativeaot-outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[am11]

@filipnavara any chance #116276 is exclusive to this PR?

[filipnavara]

@filipnavara any chance #116276 is exclusive to this PR?

Cannot rule anything out but I don't see any connection. It's NativeAOT outerloop which is not run as often as other tests.

(Will look at the Helix artifacts later to see if anything sticks out.)

[am11]

Found one hit on main: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1056334&view=ms.vss-test-web.build-test-results-tab&runId=28475296&resultId=119279&paneView=debug

@jkotas, it can randomly fail for any test using merged test executor (not specific to "Runtime_108612").

[jkotas]

None of the NativeAOT outer loop failures look related.

Thank you - great work!

[jkotas]

/ba-g unrelated infrastructure issue (failure to list devices)

[filipnavara]

Thanks for the patience with reviewing this.