Switch CoreCLR WeakReference to unified managed implementation #77196

VSadov · 2022-10-19T02:38:21Z

This is mostly about making the managed implementation aware of COM/IWeakReference. Switching by itself is trivial.

removed CoreCLR-specific managed helpers for WeakReference
switched CoreCLR to use the unified managed WeakReference (same as used in NativeAOT and Mono)
added COM/IWeakReference support to the unified managed implementation (under #ifdef)
removed the native implementation of CoreCLR WeakReference, except the eager finalization helper.
removed HNDTYPE_WEAK_NATIVE_COM

dotnet-issue-labeler · 2022-10-19T02:38:27Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

src/coreclr/nativeaot/Runtime/gcrhenv.cpp

src/libraries/System.Private.CoreLib/src/System/WeakReference.T.cs

src/libraries/System.Private.CoreLib/src/System/WeakReference.cs

VSadov · 2022-10-22T20:48:40Z

On a microbenchmark with common/ordinary objects I see:

Get object: native implementation is 77% slower.
Get null: native implementation is 149% slower. (yes, native Get takes ~2.5x longer!)
Set object: managed implementation is 21% slower.

The reasons why managed Set is a bit slower:

Assigning to a handle is an FCall to GCHandleInternalSet that JIT does not want to tailcall (can it?), and GCHandleInternalSet calls StoreObjectInHandle (also not a tail call), so managed impl has an extra call overhead. Native impl calls StoreObjectInHandle directly.
Native Set is cheating a bit (possibly a bug) - the fast path check only checks for classic COM RCWs (as in __ComObject).
Not sure if this makes a difference.
Native Create does check for wrappers, but since Create involve allocations, comparing Create would be less interesting.

runtime/src/coreclr/vm/weakreferencenative.cpp

Line 935 in e1944f1

if (pTarget == NULL || !pTarget->GetMethodTable()->IsComObjectType())

Microbenchmark that I use:

using System.Diagnostics;

internal class Program
{
    private static void Main(string[] args)
    {
        object o = new object();

        WeakReference<object>[] warr1 = new WeakReference<object>[1000];
        for(int i = 0; i < warr1.Length; i++)
        {
            warr1[i] = new WeakReference<object>(o);
        }

        WeakReference<object>[] warr2 = new WeakReference<object>[1000];
        for (int i = 0; i < warr2.Length; i++)
        {
            warr2[i] = new WeakReference<object>(null);
        }


        for (; ; )
        {
            TestGetObj(warr1);
            TestSetObj(warr1);
            TestGetNull(warr2);
            System.Console.WriteLine();
        }
    }

    private static void TestGetObj(WeakReference<object>[] warr1)
    {
        Stopwatch sw = Stopwatch.StartNew();
        for (int iter = 0; iter < 1000000; iter++)
        {
            for (int i = 0; i < warr1.Length; i++)
            {
                if (!warr1[i].TryGetTarget(out _))
                {
                    throw null;
                }
            }
        }
        sw.Stop();
        System.Console.WriteLine("Get obj:" + sw.ElapsedMilliseconds);
    }

    private static void TestSetObj(WeakReference<object>[] warr1)
    {
        Stopwatch sw = Stopwatch.StartNew();
        for (int iter = 0; iter < 1000000; iter++)
        {
            for (int i = 0; i < warr1.Length; i++)
            {
                warr1[i].SetTarget(warr1);
            }
        }
        sw.Stop();
        System.Console.WriteLine("Set obj:" + sw.ElapsedMilliseconds);
    }

    private static void TestGetNull(WeakReference<object>[] warr2)
    {
        Stopwatch sw = Stopwatch.StartNew();
        for (int iter = 0; iter < 1000000; iter++)
        {
            for (int i = 0; i < warr2.Length; i++)
            {
                if (warr2[i].TryGetTarget(out _))
                {
                    throw null;
                }
            }
        }
        sw.Stop();
        System.Console.WriteLine("Get null:" + sw.ElapsedMilliseconds);
    }
}

Sample output with changes (based off main branch), lower is better:

Get obj:836
Set obj:7573
Get null:836

Get obj:830
Set obj:7645
Get null:837

Get obj:833
Set obj:7479
Get null:833

Get obj:838
Set obj:7633
Get null:835

Get obj:839
Set obj:7722
Get null:833

Baseline - Recently published 7.0 bits:

Get obj:1464
Set obj:6167
Get null:2077

Get obj:1476
Set obj:6147
Get null:2082

Get obj:1475
Set obj:6150
Get null:2084

Get obj:1479
Set obj:6146
Get null:2079

Get obj:1478
Set obj:6142
Get null:2081

VSadov · 2022-10-29T18:57:23Z

I think this PR is ready to be reviewed/merged.

src/coreclr/vm/vars.hpp

jkotas · 2022-10-29T21:53:05Z

src/libraries/System.Private.CoreLib/src/System/ComAwareWeakReference.cs

+            return Unsafe.As<ComAwareWeakReference>(GCHandle.InternalGet(taggedHandle & ~HandleTagBits)).Target;
+        }
+
+        [MethodImpl(MethodImplOptions.NoInlining)]


This is very trivial method. Is it really worth it to disable inlining for it?

No reason. It is not even a part of some hot path any more, so there is little difference if it is inlined or not. I will let JIT decide.

jkotas · 2022-10-29T21:55:00Z

src/libraries/System.Private.CoreLib/src/System/ComAwareWeakReference.cs

+
+        ~ComAwareWeakReference()
+        {
+            GCHandle.InternalFree(_weakHandle);


Set _weakHandle to make sure that we crash in case there is a handle resurrection?

The class is intentionally internal - to make sure we control use of its instances. We should never expose it publicly and each instance should have only one reference to it - from the corresponding WeakReference via a strong handle.

That should guarantee:

noone can do lock(this) and therefore we can use lock(this) ourselves.

finalization is truly final. Since the owning handle is severed when WeakReference is finalized, the ComAwareWeakReference instance is completely unreachable from other objects when it is finalized.

I think we do not need to worry about resurrection, finalization while still constructing, use after finalization, finalization concurrent with use and other finalization issues.
These assumptions would not work with publicly exposed instances, but I think it is safe to assume here.

Right, it should all work fine when there are no bugs. Setting the _weakHandle to null is a very cheap way to ensure that we get a nice crash in case there are bugs.

jkotas · 2022-10-29T21:55:20Z

src/libraries/System.Private.CoreLib/src/System/ComAwareWeakReference.cs

+
+            ~ComInfo()
+            {
+                Marshal.Release(_pComWeakRef);


Set _pComWeakRef to null?

I think we can use the same assumptions as with ComAwareWeakReference - the instance should be finalized only once and be completely unreachable after finalization, so we do not need to zero the references.

#77196 (comment) applies here as well.

jkotas · 2022-10-29T22:02:10Z

src/libraries/System.Private.CoreLib/src/System/ComAwareWeakReference.cs

+                if (pComWeakRef == 0)
+                    return null;
+
+                return new ComInfo(pComWeakRef, wrapperId);


This will leak pComWeakRef reference when new ComInfo fails (very rare).

yes, could be worth wrapping in try/catch - just in case there is OOM or something like that.

Do we need to care about a possibility of asynchronous exception (like a ThreadAbort) after the instance is created and before the constructor finishes?

I think we generally do not harden code against ThreadAbort any more, so only OOM is an actionable concern here.

We do not care about thread abort.

jkotas · 2022-10-29T22:08:20Z

src/coreclr/gc/gcinterface.h

-     * underlying COM object as long as it has not been released by all of its strong
-     * references.
-     */
-    HNDTYPE_WEAK_NATIVE_COM   = 9


GC/VM interface change. cc @dotnet/gc

this change looks ok, assuming this enum is not shared between clrgc and coreclr? We need to ensure that latest clrgc continues to work with .net 7 runtime.

Everything in gcinterface.h is shared between clrgc and coreclr.

We need to ensure that latest clrgc continues to work with .net 7 runtime.

The changes under src/coreclr/gc need to be reverted if you would like to maintain this invariant.

continues to work with .net 7 runtime

Is this a temporary requirement?
Have we already revved the API version for the frozen string literals work?

We have added a new method to IGCHeap as part of the frozen literals work, that does not prevent new clrgc + old coreclr from working.

ok. Considering how much GC and VM are coupled, it feels like compat requirement like this is not sustainable for long. Hopefully this is just for the short term.

I don't see why that's not sustainable. we just don't delete things from the interface. yes, it'd be a bit nice to be able to delete things but considering the benefit it seems like the right tradeoff.

jkotas · 2022-10-29T22:30:07Z

src/libraries/System.Private.CoreLib/src/System/ComAwareWeakReference.cs

+            }
+
+            // see: syncblk.h
+            private const int IS_HASHCODE_BIT_NUMBER = 26;


This is CoreCLR-specific. It would be better for it to live in CoreCLR-specific file.

I will check if this can be factored out.
This will apply to NativeAOT as well, when it supports COM weak references, but may not be ever applicable to Mono.

This will apply to NativeAOT as well

Actually I am not sure. I kind of assumed the interop info is handled the same way, but that is not necessarily so.

@AaronRobinsonMSFT can you comment on support for COM weak reference support in NativeAOT?

I think support makes sense longer term - particularly as we move forward on ComWrappers. I mentioned support in some Not Yet Implemented behavior in this PR.

I think we should support weak COM references at some point within the context of overall COM support in NativeAOT.
I assume it is just a matter of dev cost and prioritization.

That is why I have added NYI call outs for NativeAOT here - so it would be clear where it will plug in.

src/libraries/System.Private.CoreLib/src/System/ComAwareWeakReference.cs

jkotas · 2022-10-29T22:39:36Z

src/coreclr/vm/weakreferencenative.cpp

    {
-        FCThrow(kNullReferenceException);
+        FC_INNER_RETURN(IWeakReference*, ObjectToComWeakRefFramed(pObject, pWrapperId, GetEEFuncEntryPointMacro(ComAwareWeakReferenceNative::ObjectToComWeakRef)));


I would rather split this into a FCall without HelperMethodFrame for the fast path, and regular QCall for the heavy lifting. (One of my very long-term goals is to get rid of all FCalls with HMF.)

I actually considered making the fast path check entirely in managed code. I already check for SyncBlock presence, so could check for interop info as well. I had concerns about whether that would be too much looking into native details from the managed code or whether that is safe if GC happens.

I will take a look.

I actually considered making the fast path check entirely in managed code.

I think it would be pushing too much sync block details to managed code. I do not think we want to do that at this point.

AaronRobinsonMSFT · 2022-10-31T15:36:53Z

src/coreclr/debug/daccess/daccess.cpp

@@ -7858,10 +7858,6 @@ void CALLBACK DacHandleWalker::EnumCallbackSOS(PTR_UNCHECKED_OBJECTREF handle, u
    data.Type = param->Type;
    if (param->Type == HNDTYPE_DEPENDENT)
        data.Secondary = GetDependentHandleSecondary(handle.GetAddr()).GetAddr();
-#ifdef FEATURE_COMINTEROP


Does this mean that SOS no longer has insight into weak references?

Regular weak references did not change from the introspection point of view.

The thing that changed is that there is no need to special case native COM weak handles, since they no longer exist. The implementation uses regular managed objects now and they will be reachable in SOS walks like any other managed object.

src/coreclr/nativeaot/Runtime/gcrhenv.cpp

AaronRobinsonMSFT · 2022-10-31T15:41:05Z

src/coreclr/nativeaot/System.Private.CoreLib/src/System/ComAwareWeakReference.NativeAot.cs

+        internal static object? ComWeakRefToObject(IntPtr pComWeakRef, long wrapperId)
+        {
+            // NativeAOT support for COM WeakReference is NYI
+            return null;


Shouldn't this throw instead? I'm assume this impl now means the it is impossible to get back to a managed object from a WeakReference. This makes sense I suppose because of the lack of general support, but I'd prefer a NotImplementedException to make this clear rather than a silent response.

Yes, I think throwing is better.

src/coreclr/vm/weakreferencenative.cpp

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

VSadov · 2022-11-01T00:05:18Z

I think all comments on this PR have been addressed. Let me know if I missed something.

jkotas · 2022-11-01T00:11:17Z

You can add a comment next to HNDTYPE_WEAK_NATIVE_COM that it can be deleted once clrgc.dll does not need to be compatible with .NET 7.

jkotas

LGTM. Nice!

src/coreclr/gc/gcinterface.h

Co-authored-by: Maoni Stephens <Maoni0@users.noreply.github.com>

VSadov · 2022-11-01T06:58:22Z

Thanks!!!

AustinWise · 2022-11-01T20:56:01Z

src/coreclr/vm/weakreferencenative.cpp

        }
 #endif // FEATURE_COMINTEROP
+        GCPROTECT_END();
+        retRcw.Set(rcwRef);


@VSadov I have not tried running this yet, but it does look a little odd to read from retRcw right after turning off the GCPROTECT on the variable. Maybe it is is OK because the GC is coop mode?

I could not find another example of ordering the GCPROTECT_END before the ObjectHandleOnStack::Set, but I could a couple examples of turning it off after setting:

runtime/src/coreclr/vm/marshalnative.cpp

Lines 1307 to 1308 in 40df8f6

retType.Set(orType);

GCPROTECT_END();

runtime/src/coreclr/vm/assemblynative.cpp

Lines 824 to 826 in 40df8f6

retTypes.Set(orTypes);

GCPROTECT_END();

The reference needs protection as long as we may be making calls that could trigger GC. In coop mode GC can happen only if we trigger it.
ObjectHandleOnStack::Set does not trigger GC, so we can stop protecting before calling it.

This can be changed as a matter of style or consistency, but I think either way is ok.

Thanks for explaining coop mode!

VSadov added 5 commits October 13, 2022 22:30

Delete managed CoreClr WR

4b6a696

all but com works

079818b

COM tests are passing

1dafd25

HandleTagBits const for NativeAot

30636bc

Exclusive Set

5876f7b

ghost assigned VSadov Oct 19, 2022

VSadov added the area-VM-coreclr label Oct 19, 2022

VSadov changed the title ~~Switching CoreCLR WeakReference to managed implementation~~ Switch CoreCLR WeakReference to unified managed implementation Oct 19, 2022

jkotas reviewed Oct 19, 2022

View reviewed changes

src/coreclr/nativeaot/Runtime/gcrhenv.cpp Outdated Show resolved Hide resolved

VSadov added 2 commits October 18, 2022 23:57

fix

9d7636c

Use sign bit

109e7a6

This was referenced Oct 19, 2022

Tracking issue for CI build timeouts #76454

Closed

Assertion failed: (*card_word)==0 in DynamicGenerics tests #76801

Closed

runfoapp bot mentioned this pull request Oct 19, 2022

Infra improvements for Helix #68176

Closed

Platforms not supporting COM can mask only one bit.

628f8c3

build-analysis bot mentioned this pull request Oct 20, 2022

Nuget restore error caused by 503s dotnet/arcade#11239

Closed

2 tasks

AaronRobinsonMSFT reviewed Oct 20, 2022

View reviewed changes

VSadov added 4 commits October 20, 2022 17:01

new approach

9ad5897

fix mono build

bf57457

check for FEATURE_COMWRAPPERS too

a917cff

stub NativeAOT support (NYI).

d42dca3

build-analysis bot mentioned this pull request Oct 21, 2022

Long running test: ReadAsync_CancelPendingTask_ThrowsCancellationException and ReadAsync_CancelPendingValueTask_ThrowsCancellationException #72586

Closed

VSadov added 4 commits October 21, 2022 15:03

current

b089f32

moved handle tags on the managed side to one location

333ae9f

Getter optimizations

99f299e

Optimizations for Setter

a119ad6

VSadov requested review from jkotas and AaronRobinsonMSFT October 22, 2022 20:54

VSadov requested review from vargaz, naricc, lambdageek, thaystg and MichalStrehovsky as code owners October 29, 2022 18:34

VSadov commented Oct 29, 2022

View reviewed changes

src/coreclr/vm/vars.hpp Show resolved Hide resolved

jkotas reviewed Oct 29, 2022

View reviewed changes

build-analysis bot mentioned this pull request Oct 29, 2022

ComInterfaceGenerator.Unit.Tests.WorkItemExecution failing with Internal CLR error on Win x86 #77087

Closed

AaronRobinsonMSFT reviewed Oct 31, 2022

View reviewed changes

VSadov and others added 5 commits October 31, 2022 10:17

Apply suggestions from code review

e51f50c

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

some PR feedback

06d66e3

GetWeakHandle no longer cares about inlining.

9bbbdb5

turn ObjectToComWeakRef into a QCall

90dd2bb

revert changes under coreclr\gc

ea7c3ee

jkotas approved these changes Nov 1, 2022

View reviewed changes

VSadov mentioned this pull request Nov 1, 2022

Delete HNDTYPE_WEAK_NATIVE_COM when no longer needed. #77703

Open

added a note to eventually remove HNDTYPE_WEAK_NATIVE_COM

a5a8a98

Maoni0 reviewed Nov 1, 2022

View reviewed changes

src/coreclr/gc/gcinterface.h Outdated Show resolved Hide resolved

Update src/coreclr/gc/gcinterface.h

230a3e6

Co-authored-by: Maoni Stephens <Maoni0@users.noreply.github.com>

mangod9 approved these changes Nov 1, 2022

View reviewed changes

build-analysis bot mentioned this pull request Nov 1, 2022

[wasm][debugger] DebuggerTests.AssignmentTests.InspectVariableBeforeAndAfterAssignment failing #64188

Closed

VSadov merged commit 7d2de49 into dotnet:main Nov 1, 2022

VSadov deleted the wr2 branch November 1, 2022 06:58

AustinWise reviewed Nov 1, 2022

View reviewed changes

VSadov mentioned this pull request Nov 9, 2022

[NativeAOT] Unify implementation of Weak References in all runtimes. #75587

Closed

ghost locked as resolved and limited conversation to collaborators Dec 6, 2022

Switch CoreCLR WeakReference to unified managed implementation #77196

Switch CoreCLR WeakReference to unified managed implementation #77196

Conversation

VSadov commented Oct 19, 2022 • edited Loading

dotnet-issue-labeler bot commented Oct 19, 2022

VSadov commented Oct 22, 2022 • edited Loading

VSadov commented Oct 29, 2022

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

VSadov Oct 30, 2022 • edited Loading

Choose a reason for hiding this comment

VSadov Oct 30, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mangod9 Oct 31, 2022 • edited Loading

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

VSadov Oct 30, 2022 • edited Loading

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

VSadov Oct 30, 2022 • edited Loading

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

VSadov commented Nov 1, 2022

jkotas commented Nov 1, 2022

jkotas left a comment

Choose a reason for hiding this comment

VSadov commented Nov 1, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

VSadov commented Oct 19, 2022 •

edited

Loading

VSadov commented Oct 22, 2022 •

edited

Loading

VSadov Oct 30, 2022 •

edited

Loading

VSadov Oct 30, 2022 •

edited

Loading

mangod9 Oct 31, 2022 •

edited

Loading

VSadov Oct 30, 2022 •

edited

Loading

VSadov Oct 30, 2022 •

edited

Loading