Include unboxing stubs in r2r images

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated

[BrzVlad]

We want to include unbox stubs in the R2R image, so they are not interpreted on ios/wasm. For this we need to create a special method that inherits from ILStubMethod. This needs to have an EmitIL implementation (for the method body) and a MethodSignature so that the method can be encoded/decoded. This new stub method will be added during dependency analysis for methods on valuetypes that can be called through an interface. These unbox stubs are included in the InstanceMethodEntryPoints table where they are encoded based on the signature (together with the other methods that not uniquely identified by a method rid). When the runtime needs to load such a stub, it will build the right signature for the unbox stub and lookup in these tables.

NativeAot already has UnboxingThunk and GenericUnboxingThunk for this purpose. These are created per generic definition and r2r inflates them as needed. They are created as method residing on an artificial BoxedValueType, which represents also the first argument they receive. UnboxingThunk simply unboxes the object and then dispatches to the target method. Given the implementation is simple, NativeAOT actually uses some custom assembly thunks for this purpose (UnboxingStubNode), which we don't yet on r2r to reduce the scope of the change. GenericUnboxingThunk handles the scenario where we need to obtain the method table instantiation from the boxed instance, so that we can pass it to the valuetype method (which expects it explicitly given it doesn't receive an object as this).

Shared generic methods are not yet handled. I believe the runtime currently expects unboxing thunks to not receive any method inst hidden arg, so additional changes might be needed there.

This bumps R2R version because an older runtime, whose SigMatchesMethodDesc doesn't check the unboxing bit, could incorrectly match a normal method with an unbox stub, due to the signatures being otherwise identical.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[hez2010]

With this change will we be able to remove the bail-out here?

runtime/src/coreclr/tools/Common/JitInterface/CorInfoImpl.cs

Lines 1621 to 1628 in 48adf80

	#if READYTORUN
	if(unboxingStub)
	{
	// We need an unboxing stub that points to an instantiated method but this is not happening in R2R.
	info->detail=CORINFO_DEVIRTUALIZATION_DETAIL.CORINFO_DEVIRTUALIZATION_FAILED_CANON;
	returnfalse;
	}

[davidwrighton]

Holistic Review

Motivation: Precompiling unboxing stubs is justified where the runtime cannot generate a usable frameless shuffle thunk, particularly on targets without runtime code generation.

Approach: The current dependency analysis is too broad because it emits a complete R2R method for every reachable unboxing stub, including common cases already handled by a much smaller runtime-generated shuffle thunk.

Summary: ⚠️ Needs Changes. Please restrict precompiled unboxing stubs to targets without runtime code generation and signatures that the runtime cannot adapt with its frameless shuffle-thunk machinery.

---

Detailed Findings

❌ Emission policy — Avoid precompiling stubs already handled by shuffle thunks

I don't think we should precompile every reachable unboxing stub. On targets that support runtime code generation, the common case is already handled by a much smaller frameless shuffle thunk. Emitting a complete R2R method for those cases increases image size without providing a clear benefit.

I think we should restrict precompiled unboxing stubs to two cases:

1. The target cannot generate code at runtime. Please use the existing ReadyToRunCompilerContext.TargetAllowsRuntimeCodeGeneration property rather than duplicating the iOS, MacCatalyst, tvOS, Browser, WASI, and Wasm target checks.
2. The runtime cannot represent the required adaptation as a frameless shuffle thunk. In particular, an instantiating unboxing stub cannot use the current shuffle machinery when adding the hidden instantiation argument requires moving or introducing an argument on the stack.

Crossgen2 should be able to approximate the second condition using its existing ArgIterator. Build the source layout as an unboxing stub, where the hidden instantiation argument is suppressed, and the destination layout as the underlying target method, where that argument is present. If the layouts have different stack-area sizes, or an argument's stack location changes, the runtime would need a framed stub and we should emit the full R2R method.

x86 must bypass this ArgIterator stack-move approximation. Its arguments are generally stack-based, but MakeUnboxingStubWorker uses the architecture-specific EmitUnboxMethodStub, which supports this calling convention without falling back to an IL stub. Accordingly, CanGenerateRuntimeShuffleThunk should return true for x86 before examining argument locations.

I suggest separating "can compile" from "should precompile" so the predicate polarity remains clear:

privatestaticboolCanCompileUnboxingStub(MethodDescmethod){return!method.RequiresInstMethodDescArg()&&!method.IsAsyncCall();}privatestaticboolShouldPrecompileUnboxingStub(MethodDescmethod){if(!CanCompileUnboxingStub(method))returnfalse;ReadyToRunCompilerContextcontext=(ReadyToRunCompilerContext)method.Context;return!context.TargetAllowsRuntimeCodeGeneration||!CanGenerateRuntimeShuffleThunk(method);}privatestaticboolCanGenerateRuntimeShuffleThunk(MethodDescmethod){// The ordinary unboxing stub only adjusts 'this' and tail-jumps.if(!method.RequiresInstMethodTableArg())returntrue;// x86 has a specialized implementation that supports its stack-based ABI.if(method.Context.Target.Architecture==TargetArchitecture.X86)returntrue;(ArgIterator<TypeHandle>source,TransitionBlocktransitionBlock)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:true);(ArgIterator<TypeHandle>destination,_)=GCRefMapBuilder.BuildArgIterator(method.Signature,method.Context,methodRequiresInstArg:method.RequiresInstArg(),isUnboxingStub:false);// GenerateShuffleArrayPortable rejects an instantiating shuffle when// the source and destination stack sizes differ.if(source.SizeOfFrameArgumentArray()!=destination.SizeOfFrameArgumentArray())returnfalse;while(true){intsourceOffset=source.GetNextOffset();intdestinationOffset=destination.GetNextOffset();Debug.Assert((sourceOffset==TransitionBlock.InvalidOffset)==(destinationOffset==TransitionBlock.InvalidOffset));if(sourceOffset==TransitionBlock.InvalidOffset)returntrue;ArgLocDesc?sourceLocation=source.GetArgLoc(sourceOffset);ArgLocDesc?destinationLocation=destination.GetArgLoc(destinationOffset);if(StackLocationChanged(transitionBlock,sourceOffset,sourceLocation,destinationOffset,destinationLocation)){returnfalse;}}staticboolStackLocationChanged(TransitionBlocktransitionBlock,intsourceOffset,ArgLocDesc?sourceLocation,intdestinationOffset,ArgLocDesc?destinationLocation){boolsourceUsesStack=transitionBlock.IsStackArgumentOffset(sourceOffset)||sourceLocationis{m_byteStackSize:>0};booldestinationUsesStack=transitionBlock.IsStackArgumentOffset(destinationOffset)||destinationLocationis{m_byteStackSize:>0};if(sourceUsesStack!=destinationUsesStack)returntrue;if(!sourceUsesStack)returnfalse;// GetArgLoc describes arguments split between registers and the stack.// If either side has such a description, conservatively require the// stack portions to be identical.if(sourceLocation.HasValue||destinationLocation.HasValue){return!sourceLocation.HasValue||!destinationLocation.HasValue||sourceLocation.Value.m_byteStackIndex!=destinationLocation.Value.m_byteStackIndex||sourceLocation.Value.m_byteStackSize!=destinationLocation.Value.m_byteStackSize;}returnsourceOffset!=destinationOffset;}}

The important behavior is:

• CanGenerateRuntimeShuffleThunk returns false when a stack move is needed.
• ShouldPrecompileUnboxingStub consequently returns true for that method.
• Ordinary all-register unboxing stubs remain runtime-generated on JIT-capable targets.
• x86 uses its specialized runtime stub instead of being classified by its normal stack-based argument convention.

Please also add coverage showing that:

• A target without runtime code generation emits an otherwise ordinary unboxing stub.
• A target with runtime code generation does not emit an ordinary/all-register unboxing stub.
• A target with runtime code generation emits an instantiating unboxing stub when adding the hidden context changes the stack layout.

Note

This review was created by GitHub Copilot.

[BrzVlad]

/azp run runtime-coreclr crossgen2 outerloop

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This change teaches ReadyToRun (R2R) to precompile and persist unboxing stubs in the R2R image, and updates the runtime lookup logic to distinguish unboxing-stub entries from “normal” entries even when they otherwise share the same signature shape. The PR also bumps the R2R minor version (27.1) and adds R2R test coverage for value-type interface/virtual dispatch scenarios that require unboxing stubs.

Changes:

• Runtime: extend signature matching and entrypoint selection so unboxing stubs are stored/loaded via InstanceMethodEntryPoints and matched using ENCODE_METHOD_SIG_UnboxingStub.
• Crossgen2/R2R compiler: generate and root unboxing thunk IL stubs, encode them with the unboxing bit in the signature, and key the instance entrypoint table in a way the runtime can probe.
• Tests/versioning: bump R2R minor version to 27.1 and add ReadyToRun tests that validate unboxing thunk presence (and runtime-function emission in a GVM case).

Reviewed changes

Copilot reviewed 23 out of 23 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/coreclr/vm/readytoruninfo.cpp	Makes SigMatchesMethodDesc validate the unboxing-stub flag and routes unboxing stubs through the instance-method entrypoint table lookup.
src/coreclr/vm/prestub.cpp	For unboxing stubs, prefers GetPrecompiledR2RCode over runtime stub generation when R2R code is available.
src/coreclr/tools/Common/Internal/Runtime/ModuleHeaders.cs	Bumps managed R2R header minor version to 27.1.
src/coreclr/tools/Common/Compiler/DependencyAnalysis/GVMDependenciesNode.cs	Adds unboxing-stub dependencies for interface GVM scenarios under #if READYTORUN.
src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs	Enhances boxed-value-type and unboxing-thunk types (mangling/sorting, target resolution helpers, and READYTORUN-specific IL emission details).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/TypeSystem/MethodDescExtensions.cs	Treats compiler-generated unboxing thunks as secondary MethodDescs and maps them back to the “primary” target MethodDesc for metadata identity.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/JitInterface/CorInfoImpl.ReadyToRun.cs	Adjusts version-bubble and shared-generic token logic to use the target method when compiling from an unboxing thunk.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/ILCompiler.ReadyToRun.csproj	Links shared boxed-types/unboxing-thunk implementation and INonEmittableType into the R2R compiler build.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/IL/ReadyToRunILProvider.cs	Supplies IL for unboxing-thunk stubs via ILStubMethod.EmitIL() when needed.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunTableManager.cs	Ensures unboxing thunks are tracked among methods requiring the “instantiated/instance entrypoint table” treatment.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/ReadyToRunCodegenCompilation.cs	Roots unboxing stubs where appropriate and ensures generated-IL tokens are available for unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRunCodegenNodeFactory.cs	Adds policy for when to precompile unboxing stubs and a factory method to materialize the correct thunk (generic vs non-generic).
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/ReadyToRun/InstanceEntryPointTableNode.cs	Encodes the unboxing bit into method signatures and hashes unboxing thunks by their target so the runtime can probe correctly.
src/coreclr/tools/aot/ILCompiler.ReadyToRun/Compiler/DependencyAnalysis/InheritedVirtualMethodsNode.cs	Adds conditional dependencies to include unboxing stubs for value-type virtual/interface dispatch cases.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCasesRunner/R2RResultChecker.cs	Adds helpers to assert presence/absence of compiled unboxing thunks in produced R2R images.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/NonGVM.cs	Adds NonGVM test cases exercising value-type interface and object virtual dispatch requiring unboxing thunks.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/VirtualMethodGenerics/GVM.cs	Adds a value-type interface GVM case to validate unboxing thunk generation for GVM scenarios.
src/coreclr/tools/aot/ILCompiler.ReadyToRun.Tests/TestCases/R2RTestSuites.cs	Asserts unboxing thunks are present for the new test cases and that GVM unboxing thunk has runtime functions.
src/coreclr/tools/aot/ILCompiler.Compiler/ILCompiler.Compiler.csproj	Switches boxed-types implementation to the shared Common file (to share behavior with R2R).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Sorting.cs	Removes boxed/unboxing thunk sorting partials (now handled in the shared boxed-types file).
src/coreclr/tools/aot/ILCompiler.Compiler/Compiler/CompilerTypeSystemContext.Mangling.cs	Removes boxed/unboxing thunk mangling partials (now handled in the shared boxed-types file).
src/coreclr/nativeaot/Runtime/inc/ModuleHeaders.h	Bumps native header minor version to 27.1 for NativeAOT runtime consumption.
src/coreclr/inc/readytorun.h	Bumps READYTORUN_MINOR_VERSION to 0x0001 and documents the 27.1 format change for unboxing stubs.

[BrzVlad]

@davidwrighton This seems like the only suspicious failure from CI, happens on wasm. Do you recall seeing this outside of my change ? https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572366/logs/539

I enabled these stubs unconditionally on desktop for my own development convenience and to get some CI testing for them. I was actually considering to switch them off completely on targets that allow jit. They don't contribute to further discoveries of dependencies, I believe they are quick to generate by the jit mechanisms at run-time and I suspect that the jit wouldn't be able to tier them up. So if we load suboptimal code for some unbox stubs, we are stuck with the r2r implementation, when the jit could have generated slightly more efficient code. Given also the detection of shuffle thunks usage seems non-trivial, I'm wondering if it would be an overall better solution to just keep these stubs on iOS/wasm for now.

[BrzVlad]

cc @pavelsavara on the r2r failure question linked above

[pavelsavara]

cc @pavelsavara on the r2r failure question linked above

I didn't see that one yet on my PRs

[pavelsavara]

@BrzVlad
Last build on main also looks OK, see https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_apis/build/builds/1572012/logs/1898

[davidwrighton]

@BrzVlad, add a switch to enable building them all the time then, and update the test suite to pass that switch to the smoke test, and make sure that test has a stub which actually gets used.

[davidwrighton]

Looks to me like there is a need to fix that build though or at least understand it more. Wasm has some places where it has found a few bugs that are much easier to hit on the wasm r2r that are also bugs for the normal crossgen platform in very unusual situations.

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws new InvalidOperationException() with no message in the default switch arm. If this is hit (e.g., due to a caller bug), the exception is not actionable and makes diagnosing signature/table mismatches much harder. Prefer throwing with a clear message that includes the unexpected method.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• The default arm in this switch throws a parameterless InvalidOperationException. This makes failures harder to diagnose and goes against the repo guidance to avoid empty exceptions for unreachable paths. Since the switch should be exhaustive when IsUnboxingThunk(method) is true, prefer UnreachableException (or at least an InvalidOperationException with a message) so unexpected thunk types are actionable.

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

• Files reviewed: 29/29 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:353

• Throwing an empty InvalidOperationException makes failures harder to diagnose (no actionable context about which MethodDesc was unexpected). This is an internal helper, but it can still surface during R2R compilation/debugging; include at least the offending method in the message.

• Files reviewed: 29/29 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

src/coreclr/tools/Common/Compiler/CompilerTypeSystemContext.BoxedTypes.cs:354

• GetTargetOfUnboxingThunk throws InvalidOperationException() with no message for the non-thunk case. If this is ever hit (e.g., a caller forgets to guard with IsUnboxingThunk), it will be difficult to diagnose which method triggered it. Include at least the offending MethodDesc in the exception message.

• Files reviewed: 31/31 changed files
• Comments generated: 0 new
• Review effort level: Lite

[BrzVlad]

/ba-g com failure unrelated