There is a pull request for your push pull branch:
It just supplies GcNode.ts which is the Gc algorithm separated from Vertex.ts . We'd have to make your sodium objects constructed lazily in order to use it.
If I find a little more free time, I'll have a go at connecting it up to Vertex. Otherwise you can have a go at it too if you feel like it.
Basically the constructor callback passed to the GcNode constructor will add this vertex to the dependents of its dependencies, and the destructor passed to the GcNode constructor will reverse that. (Remove this vertex from the dependents of its dependencies).
It seems we do not need to explicitly store the dependencies, they can be captured by the lambda expressions.
Sample usage for your SnapshotVertex:
class SnapshotVertex<A, B, C> extends StreamVertex<C> {
constructor(
sa: StreamVertex<A>,
cb: CellVertex<B>,
f: (a: A, b: B) => C,
) {
super(
new GcNode(
() => {
sa.incRef();
cb.incRef();
sa.addDependent(this);
},
() => {
sa.removeDependent(this);
sa.decRef();
cb.decRef();
},
tracer => {
tracer(sa.gcNode);
tracer(cb.gcNode);
}
)
);
this.f = f;
this.sa = sa;
this.cb = cb;
}
. . .
We should fix up and reconnect those lambda1, lambda2 etc. to your vertices too, so we can keep sodium objects alive (those without listeners) that are referenced in other lambda expressions of sodium objects that are currently alive. Those additional dependencies contained in the lambda should go through those incRef() / decRef / tracer calls too (in the lazy constructor / deconstructor / trace).
If we could team up and combined our free time available. We could knock this thing over quickly. Just need to talk to the same remote repository and commit/push often to make sure we are not duplicating each others efforts.
