<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="en-DE" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Hi everyone,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">Indeed thanks to you guys for all your input. Seems we are lacking expertise and resources here to do more research. Presumably, we will exclude the test on AIX.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">… Thomas<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="en-DE" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Thomas Stüfe <thomas.stuefe@gmail.com>
<br>
<b>Sent:</b> Tuesday, 21 November 2023 14:12<br>
<b>To:</b> David Holmes <david.holmes@oracle.com><br>
<b>Cc:</b> Hotspot dev runtime <hotspot-runtime-dev@openjdk.java.net>; Kern, Joachim <joachim.kern@sap.com>; Obermeier, Thomas <thomas.obermeier@sap.com>; Doerr, Martin <martin.doerr@sap.com><br>
<b>Subject:</b> Re: Question about JDK-8205878 (tolerating missing JNI Detach)<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="en-DE"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="en-DE">Thank you, David, for all the clarifications. I think the AIX devs have enough information now to go on searching, or to decide whether to exclude the test on AIX.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="en-DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="en-DE">Cheers, Thomas<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="en-DE"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="en-DE">On Mon, Nov 20, 2023 at 8:44 AM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="en-DE">On 20/11/2023 4:15 pm, Thomas Stüfe wrote:<br>
> Thank you, David, for explanation and confirmation!<br>
> <br>
> I try to understand what that means for SafePoints. A thread can only <br>
> have exited on its own in third-party native code. So in native, which <br>
> would make it safepoint-safe, the VM would not wait for it, right?<br>
<br>
Right.<br>
<br>
> Other than that, I wonder whether we keep pointers to thread stack in <br>
> global state somewhere. That seems to be the most obvious vulnerability.<br>
<br>
Well the obvious place would be if the thread exited with locked <br>
monitors and then we'd have a BasicObjectLock* in the object's markword. <br>
That could be a crash waiting to happen.<br>
<br>
> If this would be really an issue, I think one could add a facility that <br>
> checks threads for existence periodically, possibly as part of the JNI <br>
> check. Maybe similar to what we do in java.process, where we ascertain <br>
> identity via a (pid, start time) tupel. But as you wrote, there have <br>
> been almost no observed issues on the other *nixes.<br>
<br>
The aim here is not to try and make things safe for such errant threads <br>
- you do this and you're on your own. We just stumbled across this with <br>
a badly written test and so wanted to check that we didn't crash with <br>
the obvious cases if we operated on the java.lang.Thread.<br>
<br>
Cheers,<br>
David<br>
-----<br>
<br>
> ..Thomas<br>
> <br>
> On Mon, Nov 20, 2023 at 2:21 AM David Holmes <<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>
<br>
> <mailto:<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>>> wrote:<br>
> <br>
> Hi Thomas,<br>
> <br>
> On 18/11/2023 1:42 am, Thomas Stüfe wrote:<br>
> > Hi,<br>
> ><br>
> > the AIX folks have problems with<br>
> > runtime/jni/terminatedThread/TestTerminatedThread.java. I am<br>
> trying to<br>
> > understand some details and would be happy for pointers.<br>
> ><br>
> > The way I understand TestTerminatedThread.java and the RFR<br>
> discussion<br>
> > for 8205878 [1], the test seems to deliberately omit<br>
> > JNI_DetachCurrentThread to simulate a JNI coding error, right?<br>
> <br>
> Right.<br>
> <br>
> > It joins<br>
> > the thread, causing the OS to clean out all associated resources.<br>
> The<br>
> > pthread_t, kernel thread id, stack, etc all become invalid. The test<br>
> > then nudges the VM in various ways to shake out problems relating<br>
> to the<br>
> > continued use of these resources.<br>
> ><br>
> > Is my understanding correct, or am I missing something?<br>
> <br>
> That is correct.<br>
> <br>
> > If I got this right so far, is this not inherently unstable?<br>
> <br>
> Not sure if "unstable" is the right word but yes it can have issues.<br>
> <br>
> > What<br>
> > happens if the associated resources get reused by the libc?<br>
> pthread_t<br>
> > could be a pointer to a struct or a slot index into a table, and get<br>
> > reused by a different thread. The kernel thread id could be<br>
> reused too.<br>
> <br>
> It is an interesting question, but beyond this test what happens with<br>
> real code if that were the case? We can't detect it. We will just have<br>
> an "orphan" Thread that we can query in various ways hence ...<br>
> <br>
> ... the test is just a "canary" to see if the VM encounters any<br>
> problematic scenarios when the various API's are applied to a thread<br>
> that terminated without detaching, and which the VM can handle more<br>
> robustly.<br>
> <br>
> It turned out that other than the original CPU time issue, nothing bad<br>
> is observed on Linux, BSD/macxOS in general. We did have one case on<br>
> Linux PPC [1] were we saw something unexpected and had to adjust the<br>
> test. It may be that we need something for AIX too? Or we can skip<br>
> it on<br>
> AIX if necessary.<br>
> <br>
> Cheers,<br>
> David<br>
> <br>
> [1] <a href="https://bugs.openjdk.org/browse/JDK-8211931" target="_blank">https://bugs.openjdk.org/browse/JDK-8211931</a><br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8211931" target="_blank">https://bugs.openjdk.org/browse/JDK-8211931</a>><br>
> <br>
> <br>
> <br>
> > Thanks, Thomas<br>
> ><br>
> > [1]<br>
> ><br>
> <a href="https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html" target="_blank">https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html</a> <<a href="https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html" target="_blank">https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html</a>>
<<a href="https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html" target="_blank">https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html</a> <<a href="https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html" target="_blank">https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html</a>>><br>
> <o:p></o:p></span></p>
</blockquote>
</div>
</div>
</body>
</html>