Memory, listeners and tracking all of it

[BartAdv]

Hi,

After some reading through the sources of Sodium (mainly C# (but I guess it's same as Java), TypeScript (the one with different approach in this area) and Haskell), I still haven't got a clear picture of what are the main issues when it comes to managing memory and dependencies and what are the means to mitigate them. Let's follow couple of examples:

StreamSink<int> s = new StreamSink<int>();
Stream<string> m = s.Map(x => (x + 2).ToString());
List<string> @out = new List<string>();
using (m.Listen(@out.Add))
{
    s.Send(5);
}

In this case, the method Listen essentially just return a function that can be used to unlisten (here, it takes a form of IDisposable). But what happens if I don't dispose it, and instead clear the reference to to s, effectively losing a way to push an event into the system? Does WeakReference machinery helps here, and what's the situation in TypeScript version?

Cell<A> a1 = ...;
Cell<A> a2 = ...;
Stream<Unit> sChange = ...;
Cell<A> a = Cell.switchC(sChange.map(u -> a2).hold(a1));

(this is the example from https://github.com/SodiumFRP/sodium/issues/85#issuecomment-191948042)

In that comment, it's mentioned that "In this example we'd need to make sure the lambda u -> a2 kept a2 (which could be a whole chain of FRP logic) alive.", but later on, it's also mentioned that a2 is kept alive by the fact the closure u -> a2 is kept alive by the map operation. So I'm not sure what's the goal here - is it the need to keep something alive that would normally be garbage collected (but why), or is the goal here as usual, to not keep something alive more than it should...and how it's achieved (in both, C#/Java and TypeScript version)?

Thanks in advance, I hope to make this discussion clean and concise to avoid hand wavy descriptions and instead focus on simple examples, or maybe even references for such future discussions.

[the-real-blackh]

Hi there,

There are two basic models of memory management:

1. Finalizer-based used in languages with finalizers: Java/C#
2. Dependency tracking in other languages: Typescript/C++ (though the C++ version needs work)

BOTH implementations work this way:

• A listener that is requested will keep the object alive until it is explicitly disposed. If it's discarded, the object is still kept alive.
• The chain of dependencies for an object is also kept alive. If m = s.Map(... then m depends on s. So, while m is alive, s is kept alive.

For finalizer-based implementations:

• There is also a listenWeak() variant of listen() where the object is not kept alive if the unlisten handle is discarded. That is, GC of the unlisten handle is an implicit dispose.

For dependency-tracking implementations:

• When a listener is requested, the machinery for the whole chain of objects it depends on is activated. Before any listener is requested, the objects are in a latent state.
• If a StreamSink or CellSink is in a latent state (because nothing is listening to it - usually indirectly through a chain of dependencies), then calling send() on it is a runtime error.
• This also means that calling sample() on a cell is only going to work properly if that cell is activated by a listener. Otherwise, it's a runtime error.
• Finalizer-based implementations don't have this restriction.
• There is no listenWeak() variant of listen().

Both approaches achieve the same thing: Things are kept alive only when they are needed. Things are defined as "needed" when they are being listened to (directly or through dependencies). The rules about what happens before they are listened to are different between the two implementations.

The only thing you need to care about is how listen() works. Everything else is automatic.

Steve

[dakom]

I merged this into the wiki article at https://github.com/SodiumFRP/sodium-typescript/wiki/Memory-Management

Instead of splitting it into basic/advanced it's just a section on the page.

[clinuxrulz]

There is a trap that should be documented too:

In the expression: let cb = ca.map(x => x + 1) where ca and cb are cells. If cb is being kept alive by a listener, it does not mean ca is being kepted alive. And this is the correct behaviour, as only the stream of ca is required to keep cbs state up to date. I.E. The result of Operational.updates(ca) is instead kept alive. I fell for that trap when designing Cell::tracking, (it has been fixed in the code now though).

If ca and cb were streams in the expression above, then ca would be kept alive while cb is listened to.