Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

@EgorBot -amd -arm

using System.Reflection;
using BenchmarkDotNet.Attributes;

public class Bench
{
    public readonly int AReadonlyIntField = 42;

    [Benchmark]
    public int ReflectionFieldBoxing()
    {
        FieldInfo fieldInfo = typeof(Bench).GetTypeInfo().GetDeclaredField(nameof(AReadonlyIntField));
        Bench myInstance = new();

        object current = fieldInfo.GetValue(myInstance);

        fieldInfo.SetValue(myInstance, int.MinValue);

        return (int)current + (int)fieldInfo.GetValue(myInstance);
    }
}

@jkotas, @EgorBo, WDYT? We can get rid of this HMF and later remove the managed helpers when JIT starts inlining boxes (in Tier 0 as it does in Tier 1).

@EgorBot -windows_intel -amd -arm

using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;

public class Bench
{
    [Benchmark] public object Box8() => Box(new Buffer8());
    [Benchmark] public object Box16() => Box(new Buffer16());
    [Benchmark] public object Box32() => Box(new Buffer32());
    [Benchmark] public object Box256() => Box(new Buffer256());


    [MethodImpl(MethodImplOptions.NoInlining | 
                MethodImplOptions.NoOptimization)]
    static object Box<T>(T value) => (object)value;
}

[InlineArray(1)] public struct Buffer8 {
    long _element0;
}
[InlineArray(2)] public struct Buffer16 {
    long _element0;
}
[InlineArray(4)] public struct Buffer32 {
    long _element0;
}
[InlineArray(32)] public struct Buffer256 {
    long _element0;
}

@EgorBot -windows_intel -amd -arm

using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;

public class Bench
{
    [Benchmark] public object Box8() => Box(new Buffer8());
    [Benchmark] public object Box16() => Box(new Buffer16());
    [Benchmark] public object Box32() => Box(new Buffer32());
    [Benchmark] public object Box256() => Box(new Buffer256());


    [MethodImpl(MethodImplOptions.NoInlining | 
                MethodImplOptions.NoOptimization)]
    static object Box<T>(T value) => (object)value;
}

[InlineArray(1)] public struct Buffer8 {
    long _element0;
}
[InlineArray(2)] public struct Buffer16 {
    long _element0;
}
[InlineArray(4)] public struct Buffer32 {
    long _element0;
}
[InlineArray(32)] public struct Buffer256 {
    long _element0;
}

arm32 doesn't seem to be happy with the TLV commit despite src/coreclr/vm/arm/stubs.cpp was using JIT_Box_MP_FastPortable. 🤔

arm32 doesn't seem to be happy with the TLV commit

arm32 had the special alignment code path (RequiresAlign8)

NativeAOT's AllocFast mechanism is much efficient, maybe coreclr can reuse it via asm sharing being introduced in #114982?

Alternatively, JIT can optimize/inline InternalAlloc{NoChecks}. It will not only speed up the existing helpers, but also allow us to complete all remaining HMFs; basically all the remaining ones are due to Alloc GC API call Allocate{Object,String,Array} end up calling GCHeapUtilities::GetGCHeap()->Alloc() and therefore require HELPER_METHOD_FRAME. If we move them to C# today as-is, they will show mixed regressions, just likt JIT_Box which also requrie HMF due to AllocateOjbect call in the fallback path.

NativeAOT's AllocFast mechanism is much efficient, maybe coreclr can reuse it via asm sharing being introduced in #114982?

I'm unsure if there is behavioral difference: #105949
But sharing allocation stubs between coreclr and nativeaot should be very appealing.

GetBoxInfo and similar methods serve two purposes:
...
I do not see a good way to get rid of the validation part.

Agreed. I tried to reuse GetBoxInfo, pretty much as-is, from CastHelpers.Box, just converted to FCall. The performance of this experiment was not great (roughly 2x the baseline).

Thanks @jkotas, @EgorBo and @filipnavara for the help!

Do you think we can bring the rest of these to the same plan:

or would they (some of them?) require different approach?

I'd think that they are good candidate for implementing in assembly and sharing with NativeAOT (as per #115134 (comment)). For some of them it looks like a quite straightforward mapping but perhaps I was just lucky to look at the ones that match up closely...

Sounds good. Then we can follow @davidwrighton's footsteps once #114982 is completed. :)

Then we can follow @davidwrighton's footsteps once #114982 is completed. :)

JFYI I have a prototype on top of #114982 that moves AllocFast.S/asm to the shared code base and replaces most of the helpers. Still needs a bit of love but wanted to let you know to avoid working on the same thing...

Thanks! Can't wait to see class HelperMethodFrame cleanup all the way up to LazyMachState::unwindLazyState, which has one of 13 calls to PAL_VirtualUnwind -> unw_step. 😁