A way to explicitly break references to an instance of a class

[StellarWolfEntertainment]

I know that the first thought on this will be 'C# uses automatic memory management' and whatnot, but my proposal is an addition to such a system, not an interference of, but a way to 'manually' break references to an instance leaving it unreachable and thus eligible for collection by GC, this wouldn't force collection, or even indicate to GC that it should be collected, it would only make that instance eligible for it, at which point GC will collect when it gets to it.

[Suchiman]

So you expect this API to walk the entire heap and all the thread stacks to find all possible references to the given object and then set them to null? Aside from that this would break invariants/expectations, would induce race conditions (e.g. given if (obj != null) obj.DoSomething();, the proposed method could set obj to null between the check and the usage) and be very costly (scanning through the entire GC heap is not cheap), what would be the usecase for this? Why do you need it? Especially if you don't even intend to free the object immediately.

[huoyaoyuan]

Don't try to manually use GC. It harms performance a lot, since dealing one object will pay for nearly the same overhead with collecting the whole heap.

a class can 'destroy' itself (not just dispose of itself, but for all intents and purposes destroy) meaning that similar to the concept of disposal a class is no longer 'valid'

The memory of a single object doesn't matter, except large collections. The thing really matters is the users to the object. How do users know the object is deleted at other place? This is a common source of wild pointer in C++.

GC which is automatic memory management

GC is the memory management. It manages two contracts: unreferenced objects are released at some time, and referenced objects are always available with correct reference.

[Clockwork-Muse]

If it's the class destroying itself, then the better option would be for the class to simply release its own internal data elements (and mark as "invalid").
This assumes that the internal data consumes significant memory or other resources. Otherwise it wouldn't be of much benefit.

HOWEVER

Part of the problem is that you have to figure out to send such a signal to a given class.... you could wire up a Timer or similar, but a better option exists; just use a (potentially single element) MemoryCache. Then, so long as everything only references a borrow from the cache (doesn't save it in a member variable), it can naturally be cleaned up after an eviction period.

Note that your real problem here is that you aren't correctly accounting for lifetimes and/or ownership. If this method existed, I would fail the code review of (almost?) any piece of code using it, because it illustrates poor system/application design.

Also, this sort of thing is why we end up with serious security problems like use-after-free.

[StellarWolfEntertainment]

the specific use case I need it for, is that part of a composition system, where the 'components' of the 'object type' are useless if not attached to the base object, the base object can track, add, get and remove components from itself, but the act of 'removing' a component should mean that, that component no longer exists at all (ie is null), in this use the 'base' object owns and is responsible for the lifetime of the component, including ensuring that once removed, nothing anywhere is 'looking' at it. In regards to the reason I was hoping for something like this, I don't know how much data, or memory it might consume, just that if you remove what is effectively an attribute of an object, that attribute for that object simply ceases to exist

[Clockwork-Muse]

Yes, this is an ownership problem.

Make all components implement IDisposable. When they get removed, have their owner call Dispose(), and have the component internally mark itself invalid. Then if something attempts to use it, throw ObjectDisposedException.

[StellarWolfEntertainment]

this is how I was doing it, and in order for that to work there was a ridiculous amount of boilerplate involved, in every property, method etc of every type that derived from Component and in Component itself, whereas being able to simply 'destroy' the references to an object allows for less boilerplate (overall, none related to it's state) as the 'state' of the object would now be 'null' (in the global state), instead of 'disposed' (in the local state)

[colejohnson66]

Are you looking for something like a weak reference?

[colejohnson66]

If I’m understanding you right, it sounds like you want some object manager to have a “strong” reference to an object and all downstream consumers to have a “weak” reference. If done properly, the object manager can “destroy” objects by setting its own reference to null. You can’t immediately destroy them, however, as it will still be “live” until the garbage collector does the real destruction; Until it’s garbage collected, weak references can still use the object. You could force a collection with GC.Collect(), but that’s a terrible idea.

Unfortunately, your desire is akin to strong/weak references, but with manual memory management - something C# does not provide. There’s been some requests for a way to “disable” the garbage collector (and force manual memory management), but they aren’t popular ideas.

Potentially, you could have a wrapper type that acts like a weak reference, but with the ability to “force dead” objects:

public class MyWeakReference<T>
{
    private WeakReference<T> _target;
    private bool _forceDead;

    // should only ever be called by object manager
    internal MyWeakReference(T obj)
    {
        _target = new(obj);
    }

    // also should only be called by object manager
    internal void Destroy()
    {
        _forceDead = true;
    }

    public bool TryGetValue([NotNullWhen(true)] out T? target)
    {
        if (!_forceDead && _target.TryGetValue(out T? temp))
        {
            target = temp;
            return true;
        }

        target = null;
        return false;
    }
}

The idea is that the object manager only provides access to MyWeakReference<T> objects and nothing else. Consumers would be forced to “try get” the target. When the manager decides to destroy an object, it can set the “force dead” flag that prevents access to the target even if it’s still “live”.

If desired, you could have “try get value” return the weak reference itself to prevent consumers from holding onto such a strong reference.

This does require the object manager holding a strong reference to the target and a weak reference through this wrapper (so consumers all get the same wrapped instance that the manager could destroy), but you’re running up against the limits of the language and the runtime here. This is how such an implementation would look:

// class variables
private MyObject? _myObj = …;
private MyWeakReference<MyObject> _myObjWeak = new(_myObj);

public MyWeakReference<MyObject> MyObj => _myObjWeak;

// in some method
_myObj = null; // remove the only strong reference, which makes it eligible for GC
_myObjWeak.Destroy(); // prevent all consumers from using it

[StellarWolfEntertainment]

I'm certainly not looking for a way to disable or 'turn off' GC (that really is a terrible idea), and I'm not even looking for a way to override GC either, in practice my idea doesn't destroy it immediately either, it just 'acts' like it is, in that anything trying to access that memory (other than GC) would result in a NullReferenceException as if it had already been destroyed.

[colejohnson66]

As I said, a weak reference is the best you’re gonna get. Forcefully nullifying a strong reference underneath me violates many good practices. If you can cause the following this into throwing an NRE, I personally would not want to work with any code you’re writing:

MyObject? copy = GetObject();
if (copy is not null)
{
    // context switch here where object destroyed before resuming
    copy.DoStuff(); // object exists but NRE???
}

Using weak references forces you to acquire a strong reference to the target, even if only temporarily. Perhaps you could write an analyzer to ensure someone doesn’t store the strong reference (from TryGetTarget) to a class field, but destroying a strong reference is never gonna fly.

Perhaps you could augment the MyWeakReference code I wrote above where you force users to work on the target through a lambda:

public void Use(Action<T> action)
{
    // you could throw NRE, but I’d argue that only the runtime should be throwing them
    if (_forceDead || !_target.TryGetValue(out T? temp))
        throw new InvalidOperationException();

    action(temp);
}

Of course, nothing stops someone storing the lambda parameter to a field (extending its lifetime) such as MyObject.Use(a => this._field = a). Again, an analyzer is probably a good idea there.

[StellarWolfEntertainment]

as always I have more to learn because I didn't even know that this situation could occur,

MyObject? copy = GetObject();
if (copy is not null)
{
    // context switch here where object destroyed before resuming
    copy.DoStuff(); // object exists but NRE???
}

I always assumed that code ran more or less sequentially, thus that situation couldn't happen, I probably would have if I spent more time working with multi-threaded software.

[Clockwork-Muse]

thus that situation couldn't happen

You can't currently, but your proposal would enable it. That's what the comment is referring to.
You also don't strictly even require the context switch, as you could just "luck out" into the NRE happening on another core.

I always assumed that code ran more or less sequentially ... I probably would have if I spent more time working with multi-threaded software.

BAHAHAHA
Due to optimizations in both the JIT and at the hardware level, you aren't guaranteed the sequential order you wrote into your code is the actual order at execution time, for even single-threaded code.
Multi-threaded/concurrent execution can have bizarre behavior if you're not expecting it.