<div dir="ltr"><div>For the CompletableFuture itself: I recommended sharing it as a CompletionStage instead, since that is not mutable.<br></div><div>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. :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 28, 2016 at 8:26 PM, Alex Otenko <span dir="ltr"><<a href="mailto:oleksandr.otenko@gmail.com" target="_blank">oleksandr.otenko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">What is? Reusability?<div><br></div><div>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.<span class="HOEnZb"><font color="#888888"><br><div><br></div><div>Alex</div></font></span><div><div class="h5"><div><br><div><blockquote type="cite"><div>On 28 Jul 2016, at 16:17, Viktor Klang <<a href="mailto:viktor.klang@gmail.com" target="_blank">viktor.klang@gmail.com</a>> wrote:</div><br><div><p dir="ltr">Isn't this a general requirement for concurrency (coordination) structures?</p><p dir="ltr">-- <br>
Cheers,<br>
√</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Jul 28, 2016 11:57, "Alex Otenko" <<a href="mailto:oleksandr.otenko@gmail.com" target="_blank">oleksandr.otenko@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Alex<br>
<br>
> On 24 Jul 2016, at 19:11, Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>> wrote:<br>
><br>
> Hi Martin,<br>
><br>
> Quite a strong statement. I don't think an isolated fact of mutability<br>
> of an entity precludes us from reusing this entity (pool of objects?<br>
> reusable buffers?).<br>
><br>
> You're talking about obtrudeException(Throwable ex) and obtrudeValue(T<br>
> value), right? In my example the CF was returned by an API to a user<br>
> and this CF was completed prior to be returned.<br>
><br>
> On Sun, Jul 24, 2016 at 5:19 PM, Martin Buchholz <<a href="mailto:martinrb@google.com" target="_blank">martinrb@google.com</a>> wrote:<br>
>> Don't reuse CompletableFutures.<br>
>> Most obviously because they're mutable.<br>
>><br>
>> See also <a href="https://bugs.openjdk.java.net/browse/JDK-8161600" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8161600</a><br>
>><br>
>> On Sun, Jul 24, 2016 at 5:57 AM, Pavel Rappo <<a href="mailto:pavel.rappo@gmail.com" target="_blank">pavel.rappo@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> Is it generally safe to reuse an instance of CompletableFuture? Or am I<br>
>>> risking<br>
>>> with memory leaks due to dependants build up?<br>
>>><br>
>>> Say, I have a method that returns a CF. In some cases it may return a CF<br>
>>> straight away indicating that the action has been already done. Should I<br>
>>> always<br>
>>> create a new completed CF, or can I reuse a pre-cached one?<br>
>>><br>
>>> There's a comment in the class itself, but I'm not sure I understand it<br>
>>> enough<br>
>>> to make a conclusion:<br>
>>><br>
>>>     * ...Without precautions, CompletableFutures would be prone to<br>
>>>     * garbage accumulation as chains of Completions build up, each<br>
>>>     * pointing back to its sources. So we null out fields as soon as<br>
>>>     * possible.  The screening checks needed anyway harmlessly ignore<br>
>>>     * null arguments that may have been obtained during races with<br>
>>>     * threads nulling out fields.  We also try to unlink non-isLive<br>
>>>     * (fired or cancelled) Completions from stacks that might<br>
>>>     * otherwise never be popped: Method cleanStack always unlinks non<br>
>>>     * isLive completions from the head of stack; others may<br>
>>>     * occasionally remain if racing with other cancellations or<br>
>>>     * removals...<br>
>>><br>
>>> Thanks,<br>
>>> -Pavel<br>
>>> _______________________________________________<br>
>>> Concurrency-interest mailing list<br>
>>> <a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
>>> <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
>><br>
>><br>
> _______________________________________________<br>
> Concurrency-interest mailing list<br>
> <a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
> <a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
<br>
_______________________________________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/listinfo/concurrency-interest</a><br>
</blockquote></div></div>
</div></blockquote></div><br></div></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="border-collapse:separate;color:rgb(0,0,0);font-family:Times;font-variant:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13.333333969116211px">Cheers,</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13.333333969116211px">√</div></span></div></div></div>
</div>