<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Jige,</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
The current behavior is what's currently achievable within the constraints of the Gatherer-model, if that changes in the future it would also mean that there could be stronger "guarantees" made.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
In the mean time, the good news is that if you're not satisfied with the behavior offered by mapConcurrent()—you can create your own which does what you want it to do!</div>
<div id="Signature">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,<br>
√</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b><br>
</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Viktor Klang</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Software Architect, Java Platform Group<br>
Oracle</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Jige Yu <yujige@gmail.com><br>
<b>Sent:</b> Sunday, 13 July 2025 05:54<br>
<b>To:</b> Viktor Klang <viktor.klang@oracle.com><br>
<b>Cc:</b> core-libs-dev@openjdk.org <core-libs-dev@openjdk.org><br>
<b>Subject:</b> Re: [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees</font>
<div> </div>
</div>
<div>
<div dir="ltr">Thanks for pressing on that, Viktor!
<div><br>
</div>
<div>I think I was fooled by my quick-and-dirty test. As I tried to harden it, I failed to deduce consistent behavior about what parallel stream does when unchecked exceptions happen. And in fact, it seems like it does *not* interrupt pending threads (?).</div>
<div><br>
</div>
<div>With this in mind, do you consider this behavior of mapConcurrent() cancelling and joining the virtual threads on a best-effort basis acceptable trade-off?</div>
<div><br>
</div>
<div>I wonder then if it's even worth it for mapConcurrent() to try to join the threads at all? If it can sometimes join and sometimes not, why not just always fail fast? At least then you get consistent fail-fast behavior: if a thread fails to respond to interruption
and hangs, the main thread would still be able to respond to the exception.</div>
<div><br>
</div>
<div>Cheers,</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="x_gmail_quote x_gmail_quote_container">
<div dir="ltr" class="x_gmail_attr">On Tue, Jul 8, 2025 at 2:34 AM Viktor Klang <<a href="mailto:viktor.klang@oracle.com">viktor.klang@oracle.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div class="x_msg6567895471522507397">
<div dir="ltr">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
>I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states
<i>no</i> happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs.</div>
<div id="x_m_6567895471522507397Signature">
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Would you mind clariying <i>exactly</i> what you mean here—<b>what</b> happens-before completion/exception?</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Cheers,<br>
√</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<b><br>
</b></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<b>Viktor Klang</b></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Software Architect, Java Platform Group<br>
Oracle</div>
</div>
<div id="x_m_6567895471522507397appendonsend"></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block; width:98%">
<div id="x_m_6567895471522507397divRplyFwdMsg">
<div style="direction:ltr; font-family:Calibri,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<b>From:</b> Jige Yu <<a href="mailto:yujige@gmail.com" target="_blank">yujige@gmail.com</a>><br>
<b>Sent:</b> Tuesday, 8 July 2025 04:26<br>
<b>To:</b> Viktor Klang <<a href="mailto:viktor.klang@oracle.com" target="_blank">viktor.klang@oracle.com</a>><br>
<b>Cc:</b> <a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a> <<a href="mailto:core-libs-dev@openjdk.org" target="_blank">core-libs-dev@openjdk.org</a>><br>
<b>Subject:</b> [External] : Re: Question about mapConcurrent() Behavior and Happens-Before Guarantees</div>
<div style="direction:ltr"> </div>
</div>
<div style="direction:ltr">Thanks for the quick reply, Viktor!</div>
<div style="direction:ltr"><br>
</div>
<div style="direction:ltr">On Mon, Jul 7, 2025 at 2:35 AM Viktor Klang <<a href="mailto:viktor.klang@oracle.com" id="x_m_6567895471522507397OWA03733348-faf5-1f9c-7469-0fc114618627" target="_blank">viktor.klang@oracle.com</a>> wrote:</div>
<blockquote style="margin:0px 0px 0px 0.8ex; padding-left:1ex; border-left:1px solid rgb(204,204,204)">
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hi Jige,</div>
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
>Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a
<code>RuntimeException</code> would be able to <b>observe all side effects</b> from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing
to respond to interruption or responding slowly.</div>
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Unless explicitly stated in the API contract, no such guarantees should be presumed to exist.</div>
</blockquote>
<div style="direction:ltr"><br>
</div>
<p style="direction:ltr">I understand that explicit API contracts are what matters. My concern, however, is that even if the API contract explicitly states
<i>no</i> happens-before guarantee upon an unchecked exception, this behavior would still be a significant deviation from established visibility standards in other JDK APIs.</p>
<p style="direction:ltr">For instance, both <b>parallel streams</b> and <code>Future.get()</code> provide a happens-before guarantee upon completion (or exceptional completion in the case of
<code>Future.get()</code>). So users will most likely take it for granted. If <code>
mapConcurrent()</code> were to <i>not</i> offer this, it would potentially be the
<b>first blocking JDK API that doesn't honor happens-before</b> in such a scenario. This inconsistency would likely be surprising and potentially confusing to users who have come to expect this behavior in concurrent programming constructs within the JDK.</p>
<blockquote style="margin:0px 0px 0px 0.8ex; padding-left:1ex; border-left:1px solid rgb(204,204,204)">
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
As for general resource-management in Stream, I have contemplated designs for Gatherer (and Collector) to be able to participate in the onClose actions, but there's a lot of ground to cover to ensure correct ordering and sufficiently-encompassing of cleanup
action execution.</div>
</blockquote>
<div style="direction:ltr"><br>
</div>
<p style="direction:ltr">Yeah. I agree that hooking into <code>onClose()</code> could provide a more reliable mechanism for cleanup.</p>
<p style="direction:ltr">My primary concern though, is the change it imposes on the call-site contract. Requiring all users of
<code>mapConcurrent()</code> to adopt a <code>try-with-resources</code> syntax, while ideal for correctness, introduces a burden and is more subject to users forgetting to do so, potentially leading to resource leaks.</p>
<p style="direction:ltr">My previously proposed <code>collectingAndThen(toList(), list -> list.stream().gather(mapConcurrent()))</code> idea, on the other hand, avoids this call-site contract change. Being a collector, it needs to first consume the input, similar
to how most <code>Collector</code>s operate. So it might be a less intrusive path to ensure proper resource handling without altering usage patterns.</p>
<blockquote style="margin:0px 0px 0px 0.8ex; padding-left:1ex; border-left:1px solid rgb(204,204,204)">
<div id="x_m_6567895471522507397x_m_3888783633770680312Signature">
<div style="direction:ltr; font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="direction:ltr; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Cheers,<br>
√</div>
<div style="direction:ltr; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="direction:ltr; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<b><br>
</b></div>
<div style="direction:ltr; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<b>Viktor Klang</b></div>
<div style="direction:ltr; font-family:Calibri,Arial,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Software Architect, Java Platform Group<br>
Oracle</div>
</div>
<div id="x_m_6567895471522507397x_m_3888783633770680312appendonsend"></div>
<hr style="direction:ltr; display:inline-block; width:98%">
<div id="x_m_6567895471522507397x_m_3888783633770680312divRplyFwdMsg">
<div style="direction:ltr; font-family:Calibri,sans-serif; font-size:11pt; color:rgb(0,0,0)">
<b>From:</b> core-libs-dev <<a href="mailto:core-libs-dev-retn@openjdk.org" id="x_m_6567895471522507397OWA9a0f1614-0d0e-45ff-bf44-ac9d53989e80" target="_blank">core-libs-dev-retn@openjdk.org</a>> on behalf of Jige Yu <<a href="mailto:yujige@gmail.com" id="x_m_6567895471522507397OWA665e320d-1bba-87cf-926a-de0761f52291" target="_blank">yujige@gmail.com</a>><br>
<b>Sent:</b> Thursday, 3 July 2025 16:36<br>
<b>To:</b> <a href="mailto:core-libs-dev@openjdk.org" id="x_m_6567895471522507397OWA9e722186-0c4f-3c81-ee03-46462c9ec9bf" target="_blank">
core-libs-dev@openjdk.org</a> <<a href="mailto:core-libs-dev@openjdk.org" id="x_m_6567895471522507397OWA4899b1d3-1eb1-020f-c1ea-a1e4f2797e52" target="_blank">core-libs-dev@openjdk.org</a>><br>
<b>Subject:</b> Question about mapConcurrent() Behavior and Happens-Before Guarantees</div>
<div style="direction:ltr"> </div>
</div>
<p style="direction:ltr">Hi JDK Core Devs,</p>
<p style="direction:ltr">I'm writing to you today with a question about the behavior of
<code>mapConcurrent()</code> and its interaction with unchecked exceptions. I've been experimenting with the API and observed that
<code>mapConcurrent()</code> blocks and joins all virtual threads upon an unchecked exception before propagating it.</p>
<p style="direction:ltr">Initially, I thought this design choice might provide a strong happens-before guarantee. My assumption was that an application catching a
<code>RuntimeException</code> would be able to <b>observe all side effects</b> from the virtual threads, even though this practice is generally discouraged. This seemed like a potentially significant advantage, outweighing the risk of a virtual thread failing
to respond to interruption or responding slowly.</p>
<p style="direction:ltr">However, I've since realized that <code>mapConcurrent()</code> cannot fully guarantee a strong happens-before relationship when an unchecked exception occurs
<i>somewhere</i> in the stream pipeline. While it can block and wait for exceptions thrown by the mapper function or downstream operations, it appears unable to intercept unchecked exceptions
<b>thrown by an upstream</b> source.</p>
<p style="direction:ltr">Consider a scenario with two input elements: if the first element starts a virtual thread, and then the second element causes an unchecked exception from the upstream
<i>before</i> reaching the <code>gather()</code> call, the virtual thread initiated by the first element would not be interrupted. This makes the "happens-before" guarantee quite nuanced in practice.</p>
<p style="direction:ltr">This brings me to my core questions:</p>
<ol start="1" style="direction:ltr">
<li>
<p role="presentation" style="direction:ltr">Is providing a happens-before guarantee upon an unchecked exception a design goal for
<code>mapConcurrent()</code>?</p>
</li><li>
<p role="presentation" style="direction:ltr">If not, would it be more desirable to
<i>not</i> join on virtual threads when unchecked exceptions occur? This would allow the application code to catch the exception sooner and avoid the risk of being blocked indefinitely.</p>
</li></ol>
<p style="direction:ltr">Thank you for your time and insights.</p>
<p style="direction:ltr">Best regards,</p>
<p style="direction:ltr">Ben Yu</p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>