[concurrency-interest] Reusing CompletableFuture

Viktor Klang viktor.klang at gmail.com
Thu Jul 28 11:17:33 EDT 2016


Isn't this a general requirement for concurrency (coordination) structures?

-- 
Cheers,
√

On Jul 28, 2016 11:57, "Alex Otenko" <oleksandr.otenko at gmail.com> wrote:

> An isolated fact of reuse is also not very meaningful. You need
> cross-board support for reuse for the bulk of memory/stateful/stateless
> objects referenced by CompletableFuture.
>
> Alex
>
> > On 24 Jul 2016, at 19:11, 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>
> wrote:
> >> 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>
> wrote:
> >>>
> >>> 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
> >>
> >>
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> 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...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160728/41b9f086/attachment.html>


More information about the Concurrency-interest mailing list