[concurrency-interest] Reusing CompletableFuture

Josh Humphries jh at squareup.com
Thu Jul 28 15:35:05 EDT 2016


Unfortunately -- unless you create a defensive copy or use a custom
subclass of CompletableFuture -- it is mutable, even as CompletionStage:

stage.toCompletableFuture().obtrudeValue(null);



----
*Josh Humphries*
Payments Engineering
Atlanta, GA  |  678-400-4867
*Square* (www.squareup.com)

On Thu, Jul 28, 2016 at 3:04 PM, Viktor Klang <viktor.klang at gmail.com>
wrote:

> For the CompletableFuture itself: I recommended sharing it as a
> CompletionStage instead, since that is not mutable.
> For the value of the CompletionStage/CompletableFuture, same rules apply
> to most concurrent datastructures: instances made available through it
> needs to either be immutable, thread-safe or the usage predictably
> harmless. :)
>
> On Thu, Jul 28, 2016 at 8:26 PM, Alex Otenko <oleksandr.otenko at gmail.com>
> wrote:
>
>> 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> 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
>>>
>>
>>
>
>
> --
> Cheers,
>>
> _______________________________________________
> 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/af30f5d2/attachment.html>


More information about the Concurrency-interest mailing list