Conversation
Code needing to check for class init would be skipped for R2R compilation, probably because at runtime we would be likely to detect the check as redundant. On iOS this means that the entire method would be interpreted which is way more expensive than a small check for class initialization. This commit adds a r2r helper for this, which will end up as a call to the standard jit helper: System.Runtime.CompilerServices.Helpers.InitClass/InitInstantiatedClass. In the example below, G<>.Touch was skipped in R2R.
```
public class G<T>
{
static Type theType;
static G()
{
theType = typeof(T);
}
[MethodImpl(MethodImplOptions.NoInlining)]
public static Type Touch()
{
return theType;
}
}
G<string>.Touch();
```
There was a problem hiding this comment.
Pull request overview
This PR adds ReadyToRun (R2R) helper support for class initialization to prevent expensive interpretation on platforms without runtime JIT support (iOS, tvOS, WASM). Previously, methods requiring class initialization checks would be entirely skipped during R2R compilation and interpreted at runtime. With these changes, the class initialization helpers are compiled ahead-of-time on non-JIT platforms while still allowing JIT optimization on platforms that support runtime code generation.
Changes:
- Added two new R2R helper enum values (0x116 and 0x117) for InitClass and InitInstClass across C# and C++ codebases
- Implemented conditional logic to use R2R helpers on iOS/WASM while allowing runtime JIT on other platforms
- Added signature parsing support for the new helper types
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/coreclr/tools/Common/Internal/Runtime/ReadyToRunConstants.cs | Added InitClass (0x116) and InitInstClass (0x117) enum values to ReadyToRunHelper |
| src/coreclr/inc/readytorun.h | Added corresponding C++ enum values READYTORUN_HELPER_InitClass and READYTORUN_HELPER_InitInstClass |
| src/coreclr/inc/readytorunhelpers.h | Mapped new R2R helpers to existing CORINFO_HELP_INITCLASS and CORINFO_HELP_INITINSTCLASS JIT helpers |
| src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/ReadyToRunSignature.cs | Added signature parsing cases for INIT_CLASS and INIT_INST_CLASS |
| src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs | Implemented conditional helper resolution based on TargetAllowsRuntimeCodeGeneration flag |
| break; | ||
|
|
||
| case CorInfoHelpFunc.CORINFO_HELP_INITCLASS: | ||
| if (!((ReadyToRunCompilerContext)_compilation.TypeSystemContext).TargetAllowsRuntimeCodeGeneration) |
There was a problem hiding this comment.
These is no point in enabling this for TargetAllowsRuntimeCodeGeneration only.
This case was NYI for R2R since it is not aligned with how static constructors get triggered for R2R. It is ok to do this as a simple fix everywhere.
Separately, we may want to look at whether the current scheme for triggering static constructors in R2R is the most efficient one. The current scheme was fine tuned for x86/x64 without W^X. It is probably not the best scheme for other arches, in particular the ones that prohibit code generation.
There was a problem hiding this comment.
I tested on osx-arm64, dynamiccodecompiled false. Simplified benchmark, where Method includes a class initialization check in the prolog:
public class TypeWithCctor
{
static TypeWithCctor() { }
public static void Method() { }
}
for (int i = 0; i < 1000000000; i++)
TypeWithCctor.Method();
Tested default r2r against a tweaked version where the R2R JIT uses the same path as normal jit instead of the CORINFO_HELP_READYTORUN_NONGCSTATIC_BASE , and implemented getSharedCCtorHelper on the R2R jitinterface side to return the init class helper.
Default r2r : 1.7s
initclass r2r : 2s
On this particular microbenchmark the patched implementation is somewhat slower. While the default r2r jit would just emit a single helper/fixup call, the INITCLASS approach emits 2, one to load the MethodTable and the second to call the InitClass helper.
I'm not sure how representative this microbenchmark is, but it seems to suggest that the current state is good and there is no need for tweaks.
There was a problem hiding this comment.
the R2R JIT uses the same path as normal jit
Was the steady state path fully inlined with no calls (check flag and do nothing if it is set)? If we were to do something here, I think we would want a scheme where the steady state path is fully inlined.
Anyway, not something to solve in this PR.
| // and handle pending work. | ||
| #define READYTORUN_MAJOR_VERSION 18 | ||
| #define READYTORUN_MINOR_VERSION 0x0001 | ||
| #define READYTORUN_MINOR_VERSION 0x0002 |
There was a problem hiding this comment.
This number is in multiple places - see comment above
| #define READYTORUN_MINOR_VERSION 0x0001 | ||
| #define READYTORUN_MINOR_VERSION 0x0002 | ||
|
|
||
| #define MINIMUM_READYTORUN_MAJOR_VERSION 18 |
There was a problem hiding this comment.
Add comment below " R2R Version 18.1 adds InitClass and InitInstClass helpers"
2 participants
Code needing to check for class init would be skipped for R2R compilation, probably because at runtime we would be likely to detect the check as redundant. On iOS this means that the entire method would be interpreted which is way more expensive than a small check for class initialization. This commit adds a r2r helper for this, which will end up as a call to the standard jit helper: System.Runtime.CompilerServices.Helpers.InitClass/InitInstantiatedClass. In the example below, G<>.Touch was skipped in R2R.