[concurrency-interest] Reusing CompletableFuture

Kasper Nielsen kasperni at gmail.com
Thu Jul 28 16:00:48 EDT 2016


copy() and minimalCompletionStage() have been added for JDK 9.

http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CompletableFuture.html#copy

http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/CompletableFuture.html#minimalCompletionStage

- Kasper


On 28 July 2016 at 21:39, Viktor Klang <viktor.klang at gmail.com> wrote:

>
>
> On Thu, Jul 28, 2016 at 9:35 PM, Josh Humphries <jh at squareup.com> wrote:
>
>> Unfortunately -- unless you create a defensive copy or use a custom
>> subclass of CompletableFuture -- it is mutable, even as CompletionStage:
>>
>> stage.toCompletableFuture().obtrudeValue(null);
>>
>
> Ouch! Having that method always return a new instance would've been safer,
> for sure.
> (I always use custom CompletionStages)
>
>
>>
>>
>>
>> ----
>> *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
>>>
>>>
>>
>
>
> --
> 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/39fec0aa/attachment.html>


More information about the Concurrency-interest mailing list