[concurrency-interest] Reusing CompletableFuture

Alex Otenko oleksandr.otenko at gmail.com
Thu Jul 28 05:52:46 EDT 2016


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



More information about the Concurrency-interest mailing list