[concurrency-interest] Reusing CompletableFuture
martinrb at google.com
Sun Jul 24 15:32:25 EDT 2016
Arguing for the other side ...
A completed future will never have a chain of dependent completions build
up because they will all be triggered, and if the future was already
completed any continuation will be executed immediately.
It may make sense to reuse CompletableFutures where the mutability has been
removed, e.g. by subclassing.
Are we safe if we override just obtrudeValue and obtrudeException on a
Should j.u.c. provide such a thing?
Should j.u.c. provide separate classes for providers and consumers (read
only!) of the future value?
On Sun, Jul 24, 2016 at 11:11 AM, Pavel Rappo <pavel.rappo at gmail.com> wrote:
> Hi Martin,
> Quite a strong statement. I don't think an isolated fact of mutability
> of an entity precludes us from reusing this entity (pool of objects?
> reusable buffers?).
> You're talking about obtrudeException(Throwable ex) and obtrudeValue(T
> value), right? In my example the CF was returned by an API to a user
> and this CF was completed prior to be returned.
> On Sun, Jul 24, 2016 at 5:19 PM, Martin Buchholz <martinrb at google.com>
> > Don't reuse CompletableFutures.
> > Most obviously because they're mutable.
> > See also https://bugs.openjdk.java.net/browse/JDK-8161600
> > On Sun, Jul 24, 2016 at 5:57 AM, Pavel Rappo <pavel.rappo at gmail.com>
> >> Hi,
> >> Is it generally safe to reuse an instance of CompletableFuture? Or am I
> >> risking
> >> with memory leaks due to dependants build up?
> >> Say, I have a method that returns a CF. In some cases it may return a CF
> >> straight away indicating that the action has been already done. Should I
> >> always
> >> create a new completed CF, or can I reuse a pre-cached one?
> >> There's a comment in the class itself, but I'm not sure I understand it
> >> enough
> >> to make a conclusion:
> >> * ...Without precautions, CompletableFutures would be prone to
> >> * garbage accumulation as chains of Completions build up, each
> >> * pointing back to its sources. So we null out fields as soon as
> >> * possible. The screening checks needed anyway harmlessly ignore
> >> * null arguments that may have been obtained during races with
> >> * threads nulling out fields. We also try to unlink non-isLive
> >> * (fired or cancelled) Completions from stacks that might
> >> * otherwise never be popped: Method cleanStack always unlinks non
> >> * isLive completions from the head of stack; others may
> >> * occasionally remain if racing with other cancellations or
> >> * removals...
> >> Thanks,
> >> -Pavel
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at cs.oswego.edu
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest