[Proposal]: Weak keyword better memory managment

[redradist]

Weak keyword better memory management

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Lets discuss if it possible and would be useful to add weak keyword for such scenarious:

class Customer
{
    weak event Action evt; // All Targets are stored by WeakReferece-s
    void Run()
    {
        var list = new List<object>();
        Action<bool> action = weak () => if (list.TryGetTarget(out List<object> lst)) lst.Count > 0; // list is captured by WeakReference-s in lambda object
    }
}

Motivation

This feature could improve the situation with leak memory

Detailed design

Drawbacks

Alternatives

Unresolved questions

Design meetings

[HaloFour]

You can already use WeakReference<T> in these cases.

[HaloFour]

Weak references are a fairly niche feature and shouldn't be used without understanding the ramifications of doing so. Those ramifications include ensuring that the captured reference is still alive, which even your example isn't doing. IMO the compiler should not encourage their use, and the API is already simple enough to use where appropriate.

[redradist]

... Those ramifications include ensuring that the captured reference is still alive, which even your example isn't doing ...

@HaloFour I checked it with this code:

if (list.TryGetTarget(out List<object> lst))

[HaloFour]

So list in that case is a WeakReference<List<object>>? That seems really confusing. There are no other cases where the compiler will silently change the type of the captured variables.

IMO, the difference between your code and using WeakReference<T> is so minor that it doesn't seem like it's worth a language feature, especially given how infrequently it really should be used.

    void Run()
    {
        var list = new List<object>();
        var wr = new WeakReference<List<object>>(list);
        Action<bool> action = weak () => if (wr.TryGetTarget(out List<object> lst)) lst.Count > 0;
    }

[redradist]

So list in that case is a WeakReference<List<object>>? That seems really confusing. There are no other cases where the compiler will silently change the type of the captured variables.

IMO, the difference between your code and using WeakReference<T> is so minor that it doesn't seem like it's worth a language feature, especially given how infrequently it really should be used.

    void Run()
    {
        var list = new List<object>();
        var wr = new WeakReference<List<object>>(list);
        Action<bool> action = weak () => if (wr.TryGetTarget(out List<object> lst)) lst.Count > 0;
    }

@HaloFour It is minor in case of small lambda, but there are lots of cases with big lambda body where is not obvious which object is captured by it

[HaloFour]

And by making it a feature with a single keyword the developer wouldn't have a choice either. All reference types would be converted silently into WeakReference<T> and the lambda would have to negotiate all of them, which could be very complicated if some combination of those references were collected but others weren't. This is very complicated territory and the developer should be forced to be very explicit about it. The feature as you've described offers no flexibility; either every reference is captured or every reference is converted to a weak reference. There is also no control over the resurrection policies. These are all things that the developer should control.

[YairHalberstadt]

@redradist I've moved this to a dicussion. For future reference, if you want to discuss something without suggesting a concrete detailed proposal, you can do so by clicking on the "dicussions" tab, and then selecting "new discussion".

[sharwell]

I'm having a difficult time understanding the proposal. Each use of WeakReference<T> needs to be associated with one or more owners of the original reference T. It's not clear what the owners are of objects in the proposal, and it's also not clear what the compiler rules are for identifying those owners.

Note that past proposals for syntax sugar for weak references suffered from similar issues, e.g. dotnet/roslyn#101, dotnet/roslyn#13950

[redradist]

If there is no object controlling the life of the weak reference, you can just replace all your WeakReference<T> with null and get a valid result. In other words, the GC is always allowed to reclaim a WeakReference<T> and start returning null unless you explicitly coded a reason for it to not do so.

@sharwell Take a look at this example:

    void Run()
    {
        var list = new List<object>();
        var wr = new WeakReference<List<object>>(list);
        Action<bool> action = weak () => if (wr.TryGetTarget(out List<object> lst)) lst.Count > 0;
    }

Owner of List is list variable

[redradist]

@sharwell

For weak event it would be nice to have it because explicitness ...

And as for me it should work only with default add and remove implementation:

weak event Action evt; // Compiles, Ok !!
weak event Action evt
{
    add => ;
    remove => ;
}; // Error, cannot implement weak event with custom add and remove !!

[CyrusNajmabadi]

Owner of List is list variable

Nothing roots the list variable. So the runtime is free to GC it. This does happen. Runtime can free items that are on stack but are otherwise unreachable.

[redradist]

Owner of List is list variable

Nothing roots the list variable. So the runtime is free to GC it. This does happen. Runtime can free items that are on stack but are otherwise unreachable.

@CyrusNajmabadi Yes, in this case runtime will free memory ... but imagine that this List is stored somewhere, then List will be alive

[CyrusNajmabadi]

I'm just explaining why the example you ave doesn't hold :) If you have another example that better explains your position here, that would be helpful. However, @sharwell's point still stands.

[huoyaoyuan]

I can understand the desire.
You are asking for language level weak event support. In this case, the object reference of the delegate will be considered weak.

This is a quite common pattern, and there's a framework class to support it. https://docs.microsoft.com/en-us/dotnet/api/system.windows.weakeventmanager

But it lives in WPF, and is not so efficient.

[redradist]

I can understand the desire.
You are asking for language level weak event support. In this case, the object reference of the delegate will be considered weak.

This is a quite common pattern, and there's a framework class to support it. https://docs.microsoft.com/en-us/dotnet/api/system.windows.weakeventmanager

But it lives in WPF, and is not so efficient.

It is not needed to use WeakManager at all, actually it could be used by wrapping captured objects by WeakReference

[canton7]

Just because it hasn't been explained a lots of detail yet, it's worth highlighting that anonymous delegates / lambdas make the whole concept of weak events really rather tricky.

Let's take a very simple example:

public class C
{
    void Run()
    {
        var list = new List<object>();
        Func<bool> action = () => list.Count > 0;
    }
}

If you take a look at the generated code:

public class C
{
    [CompilerGenerated]
    private sealed class <>c__DisplayClass0_0
    {
        public List<object> list;

        internal bool <Run>b__0()
        {
            return list.Count > 0;
        }
    }

    private void Run()
    {
        <>c__DisplayClass0_0 <>c__DisplayClass0_ = new <>c__DisplayClass0_0();
        <>c__DisplayClass0_.list = new List<object>();
        Func<bool> func = new Func<bool>(<>c__DisplayClass0_.<Run>b__0);
    }
}

As you can see, we've created this new class <>c__DisplayClass0_0. The Target of action doesn't actually have a reference to C at all -- it's got a reference to <>c__DisplayClass0_0. This means that keeping action alive won't keep C alive.

However, action is the only thing keeping <>c__DisplayClass0_0 alive. If you turn action.Target into a weak reference, then <>c__DisplayClass0_0 is going to get garbage-collected in short order, and you won't be able to invoke action any more. This will happen non-deterministically.

Life gets even worse if you do this:

public class C
{
    private int limit = 0;
    
    void Run()
    {
        var list = new List<object>();
        Func<bool> action = () => list.Count > limit;
    }
}

Now the generated code looks like this:

public class C
{
    [CompilerGenerated]
    private sealed class <>c__DisplayClass1_0
    {
        public List<object> list;

        public C <>4__this;

        internal bool <Run>b__0()
        {
            return list.Count > <>4__this.limit;
        }
    }

    private int limit = 0;

    private void Run()
    {
        <>c__DisplayClass1_0 <>c__DisplayClass1_ = new <>c__DisplayClass1_0();
        <>c__DisplayClass1_.<>4__this = this;
        <>c__DisplayClass1_.list = new List<object>();
        Func<bool> func = new Func<bool>(<>c__DisplayClass1_.<Run>b__0);
    }
}

This time, action has a reference to <>c__DisplayClass1_0, and <>c__DisplayClass1_0 has a strong reference to C.

So what we want is not for action to have a weak reference to <>c__DisplayClass1_0: we need to somehow tie the lifetime of <>c__DisplayClass1_0 to the lifetime of C, so that action.Target has a strong reference to <>c__DisplayClass1_0, but we clear that reference when C is collected.

Of course, it gets even harder:

public class C
{
    private int limit = 0;
    
    void Run(object o)
    {
        Func<bool> action = () => ((List<object>)o).Count > limit;
    }
}

And the generated code:

public class C
{
    [CompilerGenerated]
    private sealed class <>c__DisplayClass1_0
    {
        public object o;

        public C <>4__this;

        internal bool <Run>b__0()
        {
            return ((List<object>)o).Count > <>4__this.limit;
        }
    }

    private int limit = 0;

    private void Run(object o)
    {
        <>c__DisplayClass1_0 <>c__DisplayClass1_ = new <>c__DisplayClass1_0();
        <>c__DisplayClass1_.o = o;
        <>c__DisplayClass1_.<>4__this = this;
        Func<bool> func = new Func<bool>(<>c__DisplayClass1_.<Run>b__0);
    }
}

Now we need to tie the lifetime of <>c__DisplayClass1_0 to both C and the object o. How does that work? Do we somehow designate one of them as the important one, and keep the other alive until that one is collected? Or do we clear action.Target when either C or o is collected?

The upshot is that we have the following options:

1. Don't allow closures (specifically, any delegate which closes over anything from its parent's scope) in weak events. This is what some weak event libraries try to do, but annoyingly WPF's WeakEventManager does not.
2. Come up with a much more clever way of tying the lifetime of the generated <>c__DisplayClass1_0 to some other object(s).

I would love some sort of weak event support in C#, but it's a very hard problem.

[sharwell]

@canton7 this is an outstanding reply showing the issues here. I've marked it as an answer to draw attention to it. IMO, before any proposal for language support for weak could move forward, the proposal would need to be updated to explain how it would be clear to an average developer how the code should behave in each of the scenarios you listed.