Implicit GC.KeepAlive in classes with finalizers

[EgorBo]

Normally, the fact that GC is precise has no visible impact on user's code in terms of correctness, however, there are certain scenarios where developer might be expected to keep an object alive by rooting it or using GC.KeepAlive and may hit rarely reproducible bugs otherwise. It typically happens with finalizers, for example:

public class MyClass
{
    public IntPtr Handle;

    public void DoWork()
    {
        // E.g. some pinvoke
        Native.DoSomeWork(Handle);
    }

    ~MyClass()
    {
        Native.DestroyHandle(Handle); // can be invoked before DoSomeWork finishes!
    }
}

// Execution example:
new MyClass().DoWork();

Here it's not obvious that DestroyHandle(Handle) can be legally invoked while DoSomeWork(Handle) is still being executed (or even not started yet!), it happens because of the precise GC (FullOpts/Tier1) that may mark "this" object as dead after Handle field is accessed - DoWork method doesn't even have to be inlined. The only way to prevent this behavior is to add GC.KeepAlive(this); after DoSomeWork(Handle);

Numerous people were not aware about this, IMO, not obvious behavior and suspected their code is subject to potential bugs (typically, "use after free"-like). Afair, @rickbrew had to insert a lot of such GC.KeepAlive(this); in Paint.NET application, also, @kekekeks suspects they might have potential bugs in Avalonia due to this behavior.

Here is the minimal repro: https://gist.github.com/EgorBo/f30e159c634f40b82b4edc78cf373466

Proposed solution

We can artificially extend life of this pointer in all instance methods of classes with finalizers by, effectively, emitting GC.KeepAlive(this) before all returns in instance methods to significantly reduce number of potential issues in users code at a small cost of making some objects live longer than needed. It's not supposed to be a silver bullet as there are still cases where GC.KeepAlive(obj) (or rooting an object) may still be required. It might be implemented on Roslyn side (so other runtimes with precise GC won't step on this too) or in JIT's liveness analysis.

cc @jkotas

[jkotas]

I would say that this is a job for interop generators to worry about. This problem only exists in manually written low-level unsafe interop. Manually written 100% correct low-level unsafe interop is hard. I do not think that this makes it significantly simpler.

at a small cost of making some objects live longer than needed

It is not the only cost. It also increases register pressure a bit, prevents tail call optimizations, ... .

[jkotas]

The only way to prevent this behavior is to add GC.KeepAlive(this); after DoSomeWork(Handle);

Note that this is not 100% reliable solution. You can still get into trouble because resurrection. It is why we have switched BCL from HandleRef that is an explicit scheme to automatically inserts KeepAlives to SafeHandles that are 100% robust.

[jkotas]

It is why we have switched BCL from HandleRef that is an explicit scheme to automatically inserts KeepAlives to SafeHandles that are 100% robust.

If we were to build this feature, we would not be able to switch BCL interop from SafeHandles to the implicit KeepAlives. It would not pass security review. It begs the question why to build this interop feature when it is not good enough for BCL?

[rickbrew]

Objects being finalized while methods are still executing on them is completely baffling behavior when you discover it, and it just feels like a bug (in .NET/C# itself). It's not a bug in the implementation, so I'd argue it's a bug in the design (IMO of course).

Sure it (mostly) only affects low-level interop code, but a lot of code bases need that sort of thing and it's not the exclusive domain of interop experts. Even for "interop experts" it's very easy to forget that you need to use GC.KeepAlive(this), it's easy to miss during code reviews, it won't reveal itself as a bug except via random low-firing crashes, and it's exceptionally difficult to debug. I'm not sure how it could be measured, but I bet there are a lot of low-firing random/mysterious/spooky crashes all over the ecosystem that are caused by this.

In Paint.NET I solved this structurally by using an "acquire self handle" pattern in my custom COM wrappers. I'm also using a custom source generator so I don't have to write each one of these "self handles" myself. This does introduce an implicit try/finally due to using, so it hurts performance a smidge. I'm able to toss in an IsDisposed check as well, adding an extra layer of runtime state validation, so it wasn't an entirely wasted effort even if GC.KeepAlive(this) were to become automatic.

If GC.KeepAlive(this) were implicit/automatic, then I suspect that my code size would shrink a little, and performance would improve ... also a little. Maybe not enough to measure.

[ComObjectRefImpl<ID2D1Mesh>]
internal unsafe partial class D2D1Mesh
    : D2D1Resource,
      IDeviceMesh
{
    public D2D1Mesh(ID2D1Mesh* pObject)
        : base((ID2D1Resource*)pObject)
    {
        // The pointer is stashed by the base-most `ComObjectRef` class and is only accessible via the "self handle"
        // This makes it difficult to accidentally not use the "self handle"
    }

    public ITessellationSink Open()
    {
        using var self = AcquireSelfHandle(); // <-- acquire

        using ComPtr<ID2D1TessellationSink> spSink = default;
        HRESULT hr = self.pD2D1Mesh->Open(spSink.GetAddressOf()); // <-- use
        hr.ThrowOnError();

        return ComObjectRef.CreateRef<ITessellationSink>(spSink).NotNull();
    }

    // vvvvvvv Generated code (some of it anyway) vvvvvvv
    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    protected new SelfHandle AcquireSelfHandle()
    {
        return new SelfHandle(this);
    }

    protected new readonly ref struct SelfHandle
        //: IDisposable
    {
        private readonly D2D1Mesh self;

        // vvvvvvv This is where you get access to the native pointer
        public TerraFX.Interop.DirectX.ID2D1Mesh* pD2D1Mesh
        {
            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            get => (TerraFX.Interop.DirectX.ID2D1Mesh*)this.self.DangerousGetNativeObjectNoAddRef();
        }

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        public SelfHandle(D2D1Mesh self)
        {
            self.VerifyNotDisposed();
            this.self = self;
        }

        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        public void Dispose()
        {
            GC.KeepAlive(this.self); // I don't actually know if this accomplishes anything
        }
    }
}

[AaronRobinsonMSFT]

This is something every interop developer eventually hits. I'm not sure how we can fix this and instead I think the correct mitigation is to document in our https://learn.microsoft.com/dotnet/standard/native-interop/best-practices, but not attempt to hide from the user.

[cshung]

It appears that the best practice doc says nothing about finalizers, which is good because using finalizer is not really a good practice, it complicates things, a lot. Non-deterministic releases of resources , unnecessarily elongating the life time of objects, non determinism due to threading, etc. It just makes thing so much harder than doing the right thing upfront.

I wonder where does the idea of using finalizer to clean up comes from, we should probably stop teaching that. Maybe we should talk about preferring deterministic resource release through the IDisposablepattern over finalizer somewhere?

[AaronRobinsonMSFT]

It appears that the best practice doc says nothing about finalizers

Maybe we should talk about preferring deterministic resource release through the IDisposablepattern over finalizer somewhere?

Correct. Whenever the interop team is involved, finalizers are specifically discouraged for non-BCL related implementations. Instead, the IDisposable pattern is recommended.

This can be observed in the latest large interop API, ComWrappers. There are two modes that are intentionally distinct. The first is the non-deterministic finalizer approach that enables the most common scenario where users rely on the GC to handle clean-up. The second is the deterministic approach, using CreateObjectFlags.UniqueInstance, that allows usage of IDisposable.

Adding this perspective to the aformentioned best practices doc makes a lot of sense here.

[hez2010]

The most important thing is that: you won't be able to reproduce it in Debug configuration as the lifetime will be extended to the end of method implicitly.
This makes it really hard to diagnostic an issue caused by missing GC.KeepAlive as it's difficult to reproduce and locate a bug like this from a bug report in production, and you won't even be aware of such bugs during development.
IMO we should at least make the behavior of Debug the same with Release: the lifetime end after the last use to this.

[cshung]

I think this is why people start using finalizer as the resource clean up mechanism in the first place.

The first is the non-deterministic finalizer approach that enables the most common scenario where users rely on the GC to handle clean-up.

If I knew nothing about what to do, I would skim through the document, read the first thing, you told me that is the most common way of doing thing, I will do just that.

1. Do we know that using finalizer to do resource cleanup is really common?
2. Does the complexity of the problem really calls for it?
3. Do they know the consequences of the non-determinism?

Change the wordings and I think it might do some good:

1. Make it the second approach
2. Call that a rare situation, where deterministic release of resource is either infeasible or too complicated, and
3. Call out that is an advanced approach, many gotchas (like this issue), only for advanced users.

Should I think of CreateObjectFlags.UniqueInstance similar to unique_ptr? Do we have a shared_ptr variant of that? I wonder if we can make releasing through finalizer the truly last resort.

Fundamentally, managing life time of native object is a pain for managed developer. It is really just type 1 pain (i.e. figure out the logic so that we can deterministically release it) or type 2 pain (non-determinism and race condition). Type 2 pain feels way more painful than type 1, IMO.

[AaronRobinsonMSFT]

If I knew nothing about what to do, I would skim through the document, read the first thing, you told me that is the most common way of doing thing, I will do just that.

Yes, that is the expectation. Letting the GC handle object lifetime should always be the preference. It costs more to implement, but is more performant and less prone to use-after-free scenarios and corruption. In effect, the entire point of garbage collectors.

Specifically for COM, there are a few niche cases where not relying on the GC is needed. The most common involve tooling for tracking memory usage of native COM components and when COM components hold onto resources, think of file locks. Both rely on predictable lifetimes so options are needed. All other cases should let the GC manage the lifetime of the interop projection, hence the default case is what we expect users to use. Manual management via IDisposable in COM source generators or Marshal.[Final]ReleaseComObject() for built-in COM are mechaisms for allowing users to handle the less common cases.

Encouraging users, by default, to try and manually handle lifetimes with the GC is not appropriate for the .NET ecosystem. That is why we've spent multiple developer years constructing abstractions to avoid that. When users need bespoke solutions they need to reference best-practices guides and realize there is going to be pain in developing those solutions. See the effort being made for Swift interop, again we are creating abstractions to avoid the lifetime complexity in the common cases, but are providing APIs when manual management is needed.

Should I think of CreateObjectFlags.UniqueInstance similar to unique_ptr?

Sort of. It is slightly different though because RAII semantics are difficult to avoid in C++, but not calling IDisposable is easy to miss.

Do we have a shared_ptr variant of that? I wonder if we can make releasing through finalizer the truly last resort.

That is the GC and COM AddRef / Release semantics in general. The finalizer is and should remain the best practice for COM, which is why the runtime team takes great pain to audit and maintain it - so users can rely upon it. This is also true for Objective-C interop and Swift will likely have some reliance on it.