[concurrency-interest] Reusing CompletableFuture

Alex Otenko oleksandr.otenko at gmail.com
Thu Jul 28 14:26:13 EDT 2016


What is? Reusability?

I don’t know about CompletableFuture specifically, but mutability has an immense impact on the implementation, since reuse requires knowing that the mutator repurposing the structure is the last entity looking at it in the old guise. Then there are gotchas that whoever keeps a reference to it, must also have a way of knowing which version of the thing it is looking at - like, suddenly you are not allowed to pass around CompletableFuture uncontrollably, need to devise ways to solve ABA problem - which becomes a problem due to mutability.

Alex

> On 28 Jul 2016, at 16:17, Viktor Klang <viktor.klang at gmail.com> wrote:
> 
> Isn't this a general requirement for concurrency (coordination) structures?
> 
> -- 
> Cheers,
>> 
> 
> On Jul 28, 2016 11:57, "Alex Otenko" <oleksandr.otenko at gmail.com <mailto: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 <mailto: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 <mailto: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 <https://bugs.openjdk.java.net/browse/JDK-8161600>
> >>
> >> On Sun, Jul 24, 2016 at 5:57 AM, Pavel Rappo <pavel.rappo at gmail.com <mailto: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 <mailto:Concurrency-interest at cs.oswego.edu>
> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> >>
> >>
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <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/c9e0f876/attachment.html>


More information about the Concurrency-interest mailing list