Remove JitGenericHandleCache #106843

davidwrighton · 2024-08-22T22:55:04Z

It was only used for overflow scenarios from the generic dictionary (which don't happen), virtual resolution scenarios for creating delegates, and a few other rare R2R scenarios
Replace the virtual resolution scenarios with a cache of the affected data in managed code, and move the helpers to managed
- Use the GenericCache type which was previously only used on NativeAOT for Generic Virtual method resolution paths.
Just remove the pointless checks from within the various normal generic lookup paths, and since they no longer do anything interesting in their hot paths except erect a helper method frame and call a worker routine, move those jit helpers to managed as well.

dotnet-policy-service · 2024-08-22T22:55:43Z

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

jkotas · 2024-08-23T20:44:44Z

...coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/VirtualDispatchHelpers.cs

+    private static unsafe IntPtr VirtualFunctionPointerSlowpath(object obj, IntPtr classHandle, IntPtr methodHandle)
+    {
+        IntPtr result = JIT_ResolveVirtualFunctionPointer(ObjectHandleOnStack.Create(ref obj), classHandle, methodHandle);
+        lock(s_virtualFunctionPointerCache)


Regular locks can call back into user code through SynchronizationManager. It would be better for this to use Lock with useTrivialWaits=true.

- It was only used for overflow scenarios from the generic dictionary (which don't happen), virtual resolution scenarios for creating delegates, and a few other rare R2R scenarios - Replace the virtual resolution scenarios with a cache of the affected data in managed code, and move the helpers to managed - Just remove the pointless checks from within the various normal generic lookup paths Swap to using GenericCache - Make FlushCurrentCache public on GenericCache, as we need to clear this when we clean up a LoaderAllocator - Tweak algorithm for computing out of bound slots on the DictionaryLayout Update crsttypes

davidwrighton · 2024-08-27T18:43:58Z

@EgorBot -intel -arm64

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

namespace VirtualDispatchChecks
{

    class _1
    {
        public virtual string Method() => "A";
    }

    class _2 : _1
    {
        public override string Method() => "B";
    }

    class _3 : _1
    {
        public override string Method() => "C";
    }

    class _4 : _1
    {
        public override string Method() => "D";
    }

    class _5 : _1
    {
        public override string Method() => "E";
    }
    class _6 : _1
    {
        public override string Method() => "F";
    }
    class _7 : _1
    {
        public override string Method() => "F";
    }

    class _8 : _1
    {
        public override string Method() => "F";
    }

    class _9 : _1
    {
        public override string Method() => "F";
    }

    class _10 : _1
    {
        public override string Method() => "F";
    }

    public class ResolveVirtualRepeatedly
    {
        static _1 _1 = new _1();
        static _1 _2 = new _2();
        static _1 _3 = new _3();
        static _1 _4 = new _4();
        static _1 _5 = new _5();
        static _1 _6 = new _6();
        static _1 _7 = new _7();
        static _1 _8 = new _8();
        static _1 _9 = new _9();
        static _1 _10 = new _10();
        [MethodImpl(MethodImplOptions.NoInlining)]
        static _1 GetA(int index)
        {
            switch (index % 10)
            {
                case 0:
                    return _10;
                case 1: return _1;
                case 2: return _2;
                case 3: return _3;
                case 4: return _4;
                case 5: return _5;
                case 6: return _6;
                case 7: return _7;
                case 8: return _8;
                case 9: return _9;
            }
            return null!;
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        static Func<string> GetAction(int index)
        {
            return GetA(index).Method;
        }

        [Benchmark]
        public void Get1Virtual()
        {
            GetAction(0);
        }

        [Benchmark]
        public void Get10Virtual()
        {
            GetAction(0);
            GetAction(1);
            GetAction(2);
            GetAction(3);
            GetAction(4);
            GetAction(5);
            GetAction(6);
            GetAction(7);
            GetAction(8);
            GetAction(9);
        }
    }
}

EgorBot · 2024-08-27T19:05:26Z

Benchmark results on Intel

BenchmarkDotNet v0.14.0, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Intel Xeon Platinum 8370C CPU 2.80GHz, 1 CPU, 8 logical and 4 physical cores
  Job-UAKKKJ : .NET 10.0.0 (42.42.42.42424), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI
  Job-SUOWDN : .NET 10.0.0 (42.42.42.42424), X64 RyuJIT AVX-512F+CD+BW+DQ+VL+VBMI

Method	Toolchain	Mean	Error	Ratio
Get1Virtual	Main	16.24 ns	0.228 ns	1.00
Get1Virtual	PR	17.15 ns	0.188 ns	1.06

Get10Virtual	Main	164.94 ns	3.211 ns	1.00
Get10Virtual	PR	179.95 ns	3.583 ns	1.09

BDN_Artifacts.zip

EgorBot · 2024-08-27T19:07:59Z

Benchmark results on Arm64

BenchmarkDotNet v0.14.0, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Unknown processor
  Job-GBFISH : .NET 10.0.0 (42.42.42.42424), Arm64 RyuJIT AdvSIMD
  Job-UCOFWF : .NET 10.0.0 (42.42.42.42424), Arm64 RyuJIT AdvSIMD

Method	Toolchain	Mean	Error	Ratio
Get1Virtual	Main	20.61 ns	0.022 ns	1.00
Get1Virtual	PR	21.18 ns	0.149 ns	1.03

Get10Virtual	Main	215.70 ns	0.238 ns	1.00
Get10Virtual	PR	308.22 ns	0.914 ns	1.43

BDN_Artifacts.zip

EgorBo · 2024-08-27T19:17:59Z

PS: I have fixed the patch applying so commit squashing is no longer needed. Also, you can use -perf to get output of perf for a benchmark (only one [Benchmark] is expected) before/after.

@EgorBot -arm64 -perf

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

namespace VirtualDispatchChecks
{

    class _1
    {
        public virtual string Method() => "A";
    }

    class _2 : _1
    {
        public override string Method() => "B";
    }

    class _3 : _1
    {
        public override string Method() => "C";
    }

    class _4 : _1
    {
        public override string Method() => "D";
    }

    class _5 : _1
    {
        public override string Method() => "E";
    }
    class _6 : _1
    {
        public override string Method() => "F";
    }
    class _7 : _1
    {
        public override string Method() => "F";
    }

    class _8 : _1
    {
        public override string Method() => "F";
    }

    class _9 : _1
    {
        public override string Method() => "F";
    }

    class _10 : _1
    {
        public override string Method() => "F";
    }

    public class ResolveVirtualRepeatedly
    {
        static _1 _1 = new _1();
        static _1 _2 = new _2();
        static _1 _3 = new _3();
        static _1 _4 = new _4();
        static _1 _5 = new _5();
        static _1 _6 = new _6();
        static _1 _7 = new _7();
        static _1 _8 = new _8();
        static _1 _9 = new _9();
        static _1 _10 = new _10();
        [MethodImpl(MethodImplOptions.NoInlining)]
        static _1 GetA(int index)
        {
            switch (index % 10)
            {
                case 0:
                    return _10;
                case 1: return _1;
                case 2: return _2;
                case 3: return _3;
                case 4: return _4;
                case 5: return _5;
                case 6: return _6;
                case 7: return _7;
                case 8: return _8;
                case 9: return _9;
            }
            return null!;
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        static Func<string> GetAction(int index)
        {
            return GetA(index).Method;
        }

        [Benchmark]
        public void Get10Virtual()
        {
            GetAction(0);
            GetAction(1);
            GetAction(2);
            GetAction(3);
            GetAction(4);
            GetAction(5);
            GetAction(6);
            GetAction(7);
            GetAction(8);
            GetAction(9);
        }
    }
}

EgorBot · 2024-08-27T19:39:54Z

Benchmark results on Arm64

BenchmarkDotNet v0.14.0, Ubuntu 22.04.4 LTS (Jammy Jellyfish)
Unknown processor
  Job-YQNLAB : .NET 10.0.0 (42.42.42.42424), Arm64 RyuJIT AdvSIMD
  Job-AMUJHL : .NET 10.0.0 (42.42.42.42424), Arm64 RyuJIT AdvSIMD

Method	Toolchain	Mean	Error	Ratio
Get10Virtual	Main	229.3 ns	2.22 ns	1.00
Get10Virtual	PR	246.1 ns	1.62 ns	1.07

BDN_Artifacts.zip

Flame graphs: Main vs PR 🔥
Hot asm: Main vs PR
Hot functions: Main vs PR

For clean perf results, make sure you have just one [Benchmark] in your app.

davidwrighton · 2024-08-27T22:27:14Z

An analysis of these results indicates that

While universally slower with the new code, we are close enough for the performance of this relatively rare scenario.
Arm64 showed significantly lower performance once, but that appears to be a case of unlucky hash values in the hash function. Since the has function is not meaningfully changed with this PR, this is considered immaterial.
When running in actual use, this should be slightly faster. Benchmark.NET results are gathered with tiered compilation disabled, and the codegen for the function is slightly better when tiered.

jkotas · 2024-08-27T23:57:11Z

src/coreclr/System.Private.CoreLib/src/System/Reflection/LoaderAllocator.cs

@@ -34,6 +34,8 @@ internal sealed partial class LoaderAllocatorScout
            if (m_nativeLoaderAllocator == IntPtr.Zero)
                return;

+            VirtualDispatchHelpers.ClearCache();


There may be a subtle race condition:

the loader allocator is still in use when VirtualDispatchHelpers.ClearCache run

the thread is rescheduled right VirtualDispatchHelpers.ClearCache

the loader allocator becomes unreferenced

Destroy succeeds

I think we will end up with stale entries in the hashtable.

I am wondering whether this is the reason for the casting cache flush to be done while the runtime is suspended: https://github.com/dotnet/runtime/pull/106843/files#diff-060f68aac95f40dd380ee5a82dd047222232b25646f908c1ea394438e18a8709R604

…parameters for function pointer resolution - This will hopefully catch up performance with the previous implementation, and indicate whether such a change is worthwhile Move cache clearing to native code to address concern from Jan around LoaderAllocator cleanup

…iccache

davidwrighton · 2024-09-04T21:30:59Z

@EgorBot -intel -arm64

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

namespace VirtualDispatchChecks
{

    class _1
    {
        public virtual string Method() => "A";
    }

    class _2 : _1
    {
        public override string Method() => "B";
    }

    class _3 : _1
    {
        public override string Method() => "C";
    }

    class _4 : _1
    {
        public override string Method() => "D";
    }

    class _5 : _1
    {
        public override string Method() => "E";
    }
    class _6 : _1
    {
        public override string Method() => "F";
    }
    class _7 : _1
    {
        public override string Method() => "F";
    }

    class _8 : _1
    {
        public override string Method() => "F";
    }

    class _9 : _1
    {
        public override string Method() => "F";
    }

    class _10 : _1
    {
        public override string Method() => "F";
    }

    public class ResolveVirtualRepeatedly
    {
        static _1 _1 = new _1();
        static _1 _2 = new _2();
        static _1 _3 = new _3();
        static _1 _4 = new _4();
        static _1 _5 = new _5();
        static _1 _6 = new _6();
        static _1 _7 = new _7();
        static _1 _8 = new _8();
        static _1 _9 = new _9();
        static _1 _10 = new _10();
        [MethodImpl(MethodImplOptions.NoInlining)]
        static _1 GetA(int index)
        {
            switch (index % 10)
            {
                case 0:
                    return _10;
                case 1: return _1;
                case 2: return _2;
                case 3: return _3;
                case 4: return _4;
                case 5: return _5;
                case 6: return _6;
                case 7: return _7;
                case 8: return _8;
                case 9: return _9;
            }
            return null!;
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        static Func<string> GetAction(int index)
        {
            return GetA(index).Method;
        }

        [Benchmark]
        public void Get1Virtual()
        {
            GetAction(0);
        }

        [Benchmark]
        public void Get10Virtual()
        {
            GetAction(0);
            GetAction(1);
            GetAction(2);
            GetAction(3);
            GetAction(4);
            GetAction(5);
            GetAction(6);
            GetAction(7);
            GetAction(8);
            GetAction(9);
        }
    }
}

…ion for creating delegates to virtual methods. If we need to bring it back, its all isolated to this one commit

…iccache

Make the ordering of parameters correct for JIT_GenericHandleWorker

…time into remove_jitgenericcache

jkotas · 2024-09-17T07:20:13Z

Benchmark results on Intel

I am not able to reproduce this regression on Dev Box Amd. The PR is ~7% faster compared to baseline on that machine.

jkotas · 2024-09-17T02:47:46Z

...coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/VirtualDispatchHelpers.cs

+
+    [MethodImpl(MethodImplOptions.NoInlining)]
+    [DebuggerHidden]
+    private static unsafe IntPtr VirtualFunctionPointerSlowpath(object obj, IntPtr classHandle, IntPtr methodHandle)


Suggested change

private static unsafe IntPtr VirtualFunctionPointerSlowpath(object obj, IntPtr classHandle, IntPtr methodHandle)

private static unsafe IntPtr VirtualFunctionPointerSlow(object obj, IntPtr classHandle, IntPtr methodHandle)

Nit: It is the common naming convention.

(Alternatively, path should be Path.)

jkotas · 2024-09-17T03:06:13Z

src/coreclr/vm/qcallentrypoints.cpp

@@ -476,6 +477,8 @@ static const Entry s_QCall[] =
    DllImportEntry(EHEnumNext)
    DllImportEntry(AppendExceptionStackFrame)
 #endif // FEATURE_EH_FUNCLETS
+    DllImportEntry(JIT_ResolveVirtualFunctionPointer)


Nit: I would drop the JIT_ prefix. It is not used with any JIT helper that was converted to managed.

jkotas · 2024-09-17T03:31:53Z

...coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/VirtualDispatchHelpers.cs

+        public int HashCode;
+        public MethodTable* MethodTable;
+        public IntPtr ClassHandleTargetMethod;
+        public IntPtr MethodHandle;


Suggested change

public int HashCode;

public MethodTable* MethodTable;

public IntPtr ClassHandleTargetMethod;

public IntPtr MethodHandle;

public int _hashCode;

public MethodTable* _methodTable;

public IntPtr _classHandleTargetMethod;

public IntPtr _methodHandle;

Use the BCL naming convention? Also, the BCL convention is to have fields first in the type.

jkotas · 2024-09-17T03:49:26Z

...coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/VirtualDispatchHelpers.cs

+    private static unsafe IntPtr VirtualFunctionPointerSlowpath(object obj, IntPtr classHandle, IntPtr methodHandle)
+    {
+        IntPtr result = JIT_ResolveVirtualFunctionPointer(ObjectHandleOnStack.Create(ref obj), classHandle, methodHandle);
+        s_virtualFunctionPointerCache.TrySet(new VirtualResolutionData(RuntimeHelpers.GetMethodTable(obj), classHandle, methodHandle), result);


It looks a bit suspect that we are passing obj into the resolve worker, but then only use RuntimeHelpers.GetMethodTable(obj) as the cache key. Do we have correct behavior for dynamic castable here?

NativeAOT follows this rule around not caching results (for interface dispatch, but appears to have the same problem for virtual function resolution) CoreCLR does not appear to me to have logic in its dispatch behavior which avoids caching. Possibly we intended to build it, but I'm pretty sure we didn't. I can build a test case to validate my expectation if you'd like. The performance of the existing IDynamicInterfaceCastable implementation would likely be highly impacted if we change the rules here.

The result of this is a useable model, although it's not well defined in behavior. The result is that if any type uses IDynamicInterfaceCastable ... the implementor of IDynamicInterfaceCastable.GetInterfaceImplementaiton really should provide an idempotent implementation for any case where it will successfully return an implementation, or they may have surprising behavior. However, we DO have the correct cache avoidance at cast time. This means that users of types which use IDynamicInterfaceCastable experience the expected behavior.

NativeAOT follows this rule around not caching results (for interface dispatch

We may want to fix NativeAOT to match CoreCLR.

Agreed. I've opened #107999 to track this issue

jkotas · 2024-09-17T03:57:40Z

src/coreclr/vm/jithelpers.cpp

+    {
+        // We can't use GetCurrentStaticAddress, as that may throw, since it will attempt to
+        // allocate memory for statics if that hasn't happened yet. But, since we force the
+        // statics memory to be allocated before initializing g_VirtualCache or g_hVirtualCache2


Suggested change

// statics memory to be allocated before initializing g_VirtualCache or g_hVirtualCache2

// statics memory to be allocated before initializing g_VirtualCache

jkotas · 2024-09-17T04:47:12Z

src/coreclr/vm/jithelpers.cpp

+            _ASSERTE(!staticTH.IsCanonicalSubtype());
+        }
+    }
+
    pStaticMD->CheckRestore();

    // MDIL: If IL specifies callvirt/ldvirtftn it remains a "virtual" instruction


Can this comment & code be deleted?

We're supposed to support this sort of adjustment as part of ReadyToRun (since we support converting a non-virtual method into a virtual method); however, I just checked, and we don't actually have testing for the case where we construct a delegate from the target method, and the behavior at runtime is incorrect in this scenario. (We do have tests for actual dispatch conversion into a virtual method.) I intend to update the comment here, but leave the logic in place, and file a bug about the R2R behavior.

Sigh. Nevermind my previous analysis.

Converting from a non-virtual to a virtual in ReadyToRun is not a safe change from the point of view of ReadyToRun. See https://learn.microsoft.com/en-us/dotnet/core/compatibility/library-change-rules for the rules that we actively support, so an affirmative test in C# should not be written.

However, we still need to ensure that code doesn't fail in surprising ways with ReadyToRun, so we still need this logic if a customer converts from Virtual to Non-Virtual, which is ALSO a breaking change, but we can hit it if a customer fails to follow all of the rules in the above document. Keeping the existing behavior is done so that failure modes of ReadyToRun generated code are still broadly similar to the failure modes of non ReadyToRun code.

jkotas · 2024-09-17T04:50:10Z

src/coreclr/vm/jithelpers.cpp

+// Factored out most of the body of JIT_GenericHandle so it could be called easily from the CER reliability code to pre-populate the
+// cache.


Suggested change

// Factored out most of the body of JIT_GenericHandle so it could be called easily from the CER reliability code to pre-populate the

// cache.

jkotas · 2024-09-17T04:54:23Z

src/coreclr/vm/jithelpers.cpp

-    HashDatum res;
-    if (g_pJitGenericHandleCache->GetValueSpeculative(&key, &res))
-        return (CORINFO_GENERIC_HANDLE)(DictionaryEntry)res;
+Volatile<FieldDesc*> g_VirtualCache;


Suggested change

Volatile<FieldDesc*> g_VirtualCache;

Volatile<FieldDesc*> g_pVirtualFunctionPointerCache;

jkotas · 2024-09-17T05:05:32Z

...coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/VirtualDispatchHelpers.cs

+        }
+        public int HashCode;
+        public MethodTable* MethodTable;
+        public IntPtr ClassHandleTargetMethod;


Suggested change

public IntPtr ClassHandleTargetMethod;

public IntPtr ClassHandle;

JIT_ResolveVirtualFunctionPointer and most other places use classHandle. It would be nice to use the same name throughout.

If you would like to add Target to the name to disambiguate it from MethodTable, I would add it to both method handle and class handle args to make it clear that they go together, like _targetMethodHandle and _targetMethodClassHandle.

jkotas · 2024-09-17T07:16:02Z

...coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/VirtualDispatchHelpers.cs

+        [MethodImpl(MethodImplOptions.AggressiveInlining)]
+        public bool Equals(VirtualResolutionData other) =>
+            HashCode == other.HashCode &&
+            MethodTable == other.MethodTable &&


HashCode should filter out nearly all mismatches, so the rest of the method can assume that the equality check is most likely going to return true. It may help on some architectures to turn the rest of the method to just one conditional branch, something like:

public bool Equals(VirtualResolutionData other) => HashCode == other.HashCode && (((nint)MethodTable - (nint)other.MethodTable) | (ClassHandleTargetMethod - other.ClassHandleTargetMethod) | (MethodHandle - other.MethodHandle)) == 0;

jkotas

Thanks!

- It was only used for overflow scenarios from the generic dictionary (which don't happen), virtual resolution scenarios for creating delegates, and a few other rare R2R scenarios - Replace the virtual resolution scenarios with a cache of the affected data in managed code, and move the helpers to managed - Use the GenericCache type which was previously only used on NativeAOT for Generic Virtual method resolution paths. - Just remove the pointless checks from within the various normal generic lookup paths, and since they no longer do anything interesting in their hot paths except erect a helper method frame and call a worker routine, move those jit helpers to managed as well.

dotnet-issue-labeler bot added the area-VM-coreclr label Aug 22, 2024

dotnet-policy-service bot assigned davidwrighton Aug 22, 2024

jkotas reviewed Aug 23, 2024

View reviewed changes

This comment was marked as resolved.

# to view

davidwrighton force-pushed the remove_jitgenericcache branch from 6bd1b55 to 7de3762 Compare August 26, 2024 21:05

This comment was marked as resolved.

# to view

This was referenced Aug 26, 2024

restarted. Azure DevOps can't recover from restarts. dotnet/dnceng#3879

Open

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

davidwrighton added 2 commits August 27, 2024 11:37

Tweak details

a752b1b

davidwrighton force-pushed the remove_jitgenericcache branch from f774050 to a752b1b Compare August 27, 2024 18:38

davidwrighton marked this pull request as ready for review August 27, 2024 22:28

This comment was marked as resolved.

# to view

dotnet deleted a comment from EgorBot Aug 27, 2024

jkotas reviewed Aug 27, 2024

View reviewed changes

davidwrighton added 2 commits September 4, 2024 14:19

Merge branch 'main' of github.com:dotnet/runtime into remove_jitgener…

3dd827a

…iccache

davidwrighton requested a review from MichalStrehovsky as a code owner September 4, 2024 21:30

EgorBot mentioned this pull request Sep 4, 2024

EgorBot for davidwrighton in #106843 EgorBot/runtime-utils#73

Open

MichalStrehovsky removed their request for review September 4, 2024 22:13

davidwrighton added 3 commits September 10, 2024 15:26

Move generic handle helpers to managed as well

1a2f4dc

Remove unnecessary work to have a slightly more efficient implementat…

f2dba1d

…ion for creating delegates to virtual methods. If we need to bring it back, its all isolated to this one commit

Merge branch 'main' of github.com:dotnet/runtime into remove_jitgener…

a25473a

…iccache

build-analysis bot mentioned this pull request Sep 11, 2024

SIGKILL (OOM?) while running LibraryImportGenerator.Tests w/o actionable log messages or artifacts dotnet/dnceng#2496

Open

3 tasks

davidwrighton added 2 commits September 11, 2024 14:49

Add support for nested types in the DEFINE_CLASS_U pathway

41342c4

Make the ordering of parameters correct for JIT_GenericHandleWorker

Merge branch 'main' into remove_jitgenericcache

e40b2d6

build-analysis bot mentioned this pull request Sep 13, 2024

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

3 tasks

davidwrighton added 2 commits September 16, 2024 10:09

Fix MUSL build error

2301226

Merge branch 'remove_jitgenericcache' of github.com:davidwrighton/run…

2515ac3

…time into remove_jitgenericcache

jkotas reviewed Sep 17, 2024

View reviewed changes

davidwrighton mentioned this pull request Sep 18, 2024

Be consistent about caching behavior of function resolutions through IDynamicInterfaceCastable #107999

Open

Code review feedback

3ee7d3d

jkotas approved these changes Sep 18, 2024

View reviewed changes

davidwrighton merged commit 128fdfd into dotnet:main Sep 18, 2024
149 of 151 checks passed

AndyAyersMS mentioned this pull request Sep 24, 2024

[Perf] Windows/x64: 12 Improvements on 9/18/2024 11:52:02 PM dotnet/perf-autofiling-issues#41691

Closed

LoopedBard3 mentioned this pull request Sep 24, 2024

[Perf] Linux/x64: 14 Regressions on 9/18/2024 11:52:02 PM #108203

Open

AndyAyersMS mentioned this pull request Sep 24, 2024

[Perf] Windows/x64: 8 Improvements on 9/18/2024 11:52:02 PM dotnet/perf-autofiling-issues#41665

Closed

build-analysis bot mentioned this pull request Sep 5, 2024

System.Runtime.Serialization.Formatters CI failure. #107309

Closed

github-actions bot locked and limited conversation to collaborators Oct 19, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove JitGenericHandleCache #106843

Remove JitGenericHandleCache #106843

davidwrighton commented Aug 22, 2024 •

edited

Loading

dotnet-policy-service bot commented Aug 22, 2024

jkotas Aug 23, 2024

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

davidwrighton commented Aug 27, 2024

EgorBot commented Aug 27, 2024

EgorBot commented Aug 27, 2024

EgorBo commented Aug 27, 2024

EgorBot commented Aug 27, 2024

davidwrighton commented Aug 27, 2024

This comment was marked as resolved.

jkotas Aug 27, 2024

davidwrighton commented Sep 4, 2024

jkotas commented Sep 17, 2024

jkotas Sep 17, 2024

jkotas Sep 17, 2024

jkotas Sep 17, 2024

jkotas Sep 17, 2024

davidwrighton Sep 18, 2024

davidwrighton Sep 18, 2024

jkotas Sep 18, 2024

davidwrighton Sep 18, 2024

jkotas Sep 17, 2024

jkotas Sep 17, 2024

davidwrighton Sep 18, 2024

davidwrighton Sep 18, 2024

jkotas Sep 17, 2024

jkotas Sep 17, 2024

jkotas Sep 17, 2024

jkotas Sep 17, 2024

jkotas left a comment

	private static unsafe IntPtr VirtualFunctionPointerSlowpath(object obj, IntPtr classHandle, IntPtr methodHandle)
	private static unsafe IntPtr VirtualFunctionPointerSlow(object obj, IntPtr classHandle, IntPtr methodHandle)

	// statics memory to be allocated before initializing g_VirtualCache or g_hVirtualCache2
	// statics memory to be allocated before initializing g_VirtualCache

		// Factored out most of the body of JIT_GenericHandle so it could be called easily from the CER reliability code to pre-populate the
		// cache.

	Volatile<FieldDesc*> g_VirtualCache;
	Volatile<FieldDesc*> g_pVirtualFunctionPointerCache;

	public IntPtr ClassHandleTargetMethod;
	public IntPtr ClassHandle;

Remove JitGenericHandleCache #106843

Remove JitGenericHandleCache #106843

Conversation

davidwrighton commented Aug 22, 2024 • edited Loading

dotnet-policy-service bot commented Aug 22, 2024

Choose a reason for hiding this comment

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

This comment was marked as resolved.

davidwrighton commented Aug 27, 2024

EgorBot commented Aug 27, 2024

EgorBot commented Aug 27, 2024

EgorBo commented Aug 27, 2024

EgorBot commented Aug 27, 2024

davidwrighton commented Aug 27, 2024

This comment was marked as resolved.

Choose a reason for hiding this comment

davidwrighton commented Sep 4, 2024

jkotas commented Sep 17, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jkotas left a comment

Choose a reason for hiding this comment

davidwrighton commented Aug 22, 2024 •

edited

Loading