Non-intuitive object eviction from garbage collection

Question

I'm debugging a memory leak and had to dive into CompletableFuture internals. There is this piece of code (CompletableFuture.uniComposeStage):

CompletableFuture<V> g = f.apply(t).toCompletableFuture();
...
CompletableFuture<V> d = new CompletableFuture<V>();
UniRelay<V> copy = new UniRelay<V>(d, g);
g.push(copy);
copy.tryFire(SYNC);
return d;

The code itself is quite clear to me: apply a function that returns CompletionStage (g), create a relay that eventually will transfer value to another CompletableFuture (d), then return this another future (d). I see following reference situation:

• copy references both d and g (and there is no magic in constructor, only field assignments)
• g references copy
• d references nothing

Only d is returned, so, in fact, both g and copy seem as internal method variables to me, that (on first sight) should never leave the method and be eventually gc'd. Both naive testing and the fact that it was written long ago by proven developers suggests me that i'm wrong and missing something. What is the reason that make those objects being omitted from garbage collection?

Answer 1

In the cited code, there is nothing preventing garbage collection of these futures and there is no need to. This code in question applies to the scenario that the first CompletableFuture (the this instance) has been completed and the CompletableFuture returned by the directly evaluated compose function has not completed yet.

Now, there are two possible scenarios

1. There is an ongoing completion attempt. Then, the code which will eventually complete the future will hold a reference to it and when completing, it will trigger the completion of the dependent stages (registered via g.push(copy)). In this scenario, there is no need for the dependent stage to hold a reference to its prerequisite stage.

   This is a general pattern. If there is a chain x --will complete-→ y, there will be no reference from y to x.

2. There is no other reference to that CompletableFuture instance g and g has not been completed yet. In this case, it will never be completed at all and holding a reference to g internally wouldn’t change that. That would only waste resources.

The following example program will illustrate this:

public static void main(String[] args) throws Throwable {
    ReferenceQueue<Object> discovered = new ReferenceQueue<>();
    Set<WeakReference<?>> holder = new HashSet<>();

    CompletableFuture<Object> initial = CompletableFuture.completedFuture("somevalue");

    CompletableFuture<Object> finalStage = initial.thenCompose(value -> {
        CompletableFuture<Object> lost = new CompletableFuture<>();
        holder.add(new WeakReference<>(lost, discovered));
        return lost;
    });
    waitFor(finalStage, holder, discovered);
    finalStage = initial.thenCompose(value -> {
        CompletableFuture<Object> saved = CompletableFuture.supplyAsync(()-> {
            LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1));
            return "newvalue";
        });
        holder.add(new WeakReference<>(saved, discovered));
        return saved;
    });
    waitFor(finalStage, holder, discovered);
}
private static void waitFor(CompletableFuture<Object> f, Set<WeakReference<?>> holder,
                    ReferenceQueue<Object> discovered) throws InterruptedException {
    while(!f.isDone() && !holder.isEmpty()) {
        System.gc();
        Reference<?> removed = discovered.remove(100);
        if(removed != null) {
            holder.remove(removed);
            System.out.println("future has been garbage collected");
        }
    }
    if(f.isDone()) {
        System.out.println("stage completed with "+f.join());
        holder.clear();
    }
}

The first function passed to thenCompose creates and returns a new uncompleted CompletableFuture without any attempt to complete it, not holding nor storing any other reference to it. In contrast, the second function creates the CompletableFuture via supplyAsync providing a Supplier which will return a value after a second.

On my system, it consistently printed

future has been garbage collected
stage completed with newvalue

showing that the abandoned future will not be prevented from garbage collection while the other will be held at least until completion.