Fix memory leaks for token composition

[bergus]

See the case made by @stefanpenner in tc39/proposal-cancelable-promises#52

In many situations, a long-lived cancellation token (passed in by the caller) is combined with a short-lived token, e.g. in the "last" example or for a timeout:

function withTimeout(action, t) {
    return function(...args) {
        const token = args.pop();
        const timeout = new CancelToken(cancel => setTimeout(cancel, t, "timeout"));
        return action.call(this, ...args, token.concat(timeout));
    };
}

When the action is long over, and the combined token is no longer relevant to anyone, the token still holds are reference to it.
Todo:

• ensure that it is dropped, or at least not more than a constant amount of references are kept (though not ideal for tree-like dependencies).
• write refcounting test

[stefanpenner]

though not ideal for tree-like dependencies

I suspect this is a pretty common case. (in my travels, it appears to be)

[bergus]

Actually the timeout example is a bad one, as the short-lived token does reliably get cancelled here and the composed one with it, so there's nothing to cling on any more. If I remember correctly, Creed's implementation of race/concat already removes all references from the sources when the result is cancelled by any.

The real problem is when the composed token is does not get cancelled for a long time and does have no handlers (that do anything) registered. Some of their short-lived source tokens might even have been garbage-collected already, but they are still registered on some long-lived root token. In that case, we would want the single dependency to be collapsed, and the reference from the root to the composed token to be removed.

[bergus]

@stefanpenner Yeah, in general they always form tree-like dependency structures (or actually, a multitree), but they usually have a constant-bounded depth, right? So if we can keep the width (number of children, i.e. handlers) of each node constant at least, we should achieve overall constant memory.
I've made that distinction because we probably won't be able to prune the whole graph every time and still achieve necessary performance. I've successfully used similar tricks before.

Maybe you can share some examples where a large number of tokens is composed from a long-living one?

[stefanpenner]

@bergus would love to respond with some examples, but currently tied up with other stuff. If i don't respond by this upcoming monday, please feel free to pester me :)

[bergus]

@stefanpenner Seems the time for pestering has come :-) Would you like a daily interval of inquiries?