<div dir="ltr"><div>Thanks again Patricio,</div><div><br></div><div>I guess I was struggling to make the connection between the synchronized blocks and the calls to thaw. Based on your last email, I think that I understand that connection, but feel free to correct me if I'm wrong:<br><br></div><div>- There cannot be a call to thaw after a synchronized block has entered and before its execution has completed. If I think about why this is not possible, I think that a thaw cannot happen after something like Thread.yield because in that case the yield would fail and the virtual thread would be pinned. It also should not happen because of a return barrier because a thaw of that kind only happens when we need to load a higher frame in the stack, which by definition cannot happen inside a synchronized block method / block.<br><br></div><div>- held_monitor_count is only affected by synchronized methods / blocks or by JNI's MonitorEnter / MonitorExit. Other synchronization primitives in the JVM do not affect that variable.<br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 23, 2024 at 6:09 PM Patricio Chilano Mateo <<a href="mailto:patricio.chilano.mateo@oracle.com">patricio.chilano.mateo@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<br>
<div>On 7/23/24 5:59 AM, Iñigo Mediavilla
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hello Patricio,</div>
<div><br>
</div>
<div>Thanks a lot for your explanation. <br>
<br>
Why is it safe for Thaw code to assume that all non-jni
monitors will be released at that point, but the same
assumption cannot be made for jni monitors ? <br>
<br>
</div>
<div>What would happen if ?<br>
<br>
</div>
<div>1. A virtual thread is unmounted</div>
<div>2. We thaw a few frames and execute code that acquires a
non-JNI monitor<br>
</div>
<div>3. We call thaw again<br>
<br>
</div>
<div>Or is that not possible ?<br>
</div>
</div>
</blockquote>
That would not be possible unless there is a bug. All monitors
acquired from synchronized methods/blocks should have been released
once execution of the synchronized method/block completes, either
normally or abruptly (see [1]).<br>
Monitors that are acquired through JNI function MonitorEnter though
are not automatically exited and a call to JNI function MonitorExit
is required, unless DetachCurrentThread is used to implicitly
release them (see [2]).<br>
<br>
[1]
<a href="https://docs.oracle.com/javase/specs/jls/se22/html/jls-17.html#jls-17.1" target="_blank">https://docs.oracle.com/javase/specs/jls/se22/html/jls-17.html#jls-17.1</a><br>
[2]
<a href="https://docs.oracle.com/en/java/javase/22/docs/specs/jni/functions.html#monitor-operations" target="_blank">https://docs.oracle.com/en/java/javase/22/docs/specs/jni/functions.html#monitor-operations</a><br>
<br>
Patricio<br>
<blockquote type="cite">
<div dir="ltr">
<div>Thanks <br>
Íñigo<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jul 22, 2024 at
4:11 PM Patricio Chilano Mateo <<a href="mailto:patricio.chilano.mateo@oracle.com" target="_blank">patricio.chilano.mateo@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div> Hi Iñigo,<br>
<br>
The problem is that we can unmount a virtual thread, then
mount it again, thaw a few frames, execute code that
acquires a JNI monitor, and then call thaw again without
releasing that monitor. Thaw code assumes all monitors must
be released at that point but doesn't consider JNI acquired
ones. In this test this will happen if the vthread is
unmounted in System.out.println("Thread doing JNI call: "
...) because of contention with the main thread
doing System.out.println("Main waiting for event."). You can
reproduce this issue by adding Thread.yield() before
jniMonitorEnterAndLetObjectDie().<br>
<br>
Thanks,<br>
Patricio<br>
<br>
<div>On 7/22/24 7:30 AM, Iñigo Mediavilla wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>Hello Serguei,<br>
<br>
</div>
Thanks a lot for sharing the update and for solving
the issue. Do you think that you could help me
understand exactly what's happening ?<br>
<br>
</div>
<div>Based on the DBG output shared in JBS, my
understanding is that what happens in the test is the
following:<br>
</div>
<div dir="ltr"><br>
Main Thread<br>
-------------------------
----------------------------<br>
1. acquire java lock<br>
2. starting thread<br>
3. jni call<br>
4.
MonitorContendedEnter<br>
5. release java lock<br>
6. acquire java lock<br>
7.
MonitorContendedEntered<br>
8. Thread in sync
section<br>
9. release java lock<br>
10. why freeze doesn't
pin ?<br>
<br>
</div>
<div>What I'm struggling to understand is why after the
thread releases the java lock, the virtual thread is
still frozen, and specially why does it freeze while
holding a jni monitor ? I've run tests locally trying
to freeze a virtual thread holding a JNI lock and my
virtual threads are always being pinned to the carrier
with reason ("holding a lock"). <br>
<br>
</div>
<div>Thanks in advance</div>
<div><br>
</div>
<div>Íñigo<br>
</div>
<div dir="ltr"><br>
</div>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, Jul 19, 2024
at 10:41 PM Serguei Spitsyn <<a href="mailto:serguei.spitsyn@oracle.com" target="_blank">serguei.spitsyn@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div lang="EN-US">
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:14pt;font-family:"Aptos",sans-serif">Hi
</span><span style="font-size:14pt">Iñigo,</span><span style="font-size:11pt"></span></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Aptos",sans-serif">Patricio
helped to reproduce this issue and also
identified the problem (please, see in the
bug report).<br>
The fix is a one-liner. I’ll post a PR
after some mach5 testing.<br>
<br>
Thank you for involvement into this issue!<br>
<br>
Thanks,</span></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Aptos",sans-serif">Serguei</span></p>
<p class="MsoNormal"><span style="font-size:14pt;font-family:"Aptos",sans-serif"> </span></p>
<div id="m_392682158423523436m_1001536631130880633m_-4987297925683164692m_-316009806055635242mail-editor-reference-message-container">
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="font-size:12pt;font-family:"Aptos",sans-serif;color:black">From:
</span></b><span style="font-size:12pt;font-family:"Aptos",sans-serif;color:black">Iñigo
Mediavilla <<a href="mailto:imediava@gmail.com" target="_blank">imediava@gmail.com</a>><br>
<b>Date: </b>Saturday, July 13,
2024 at 12:08</span><span style="font-size:12pt;font-family:"Arial",sans-serif;color:black"> </span><span style="font-size:12pt;font-family:"Aptos",sans-serif;color:black">AM<br>
<b>To: </b>Chris Plummer <<a href="mailto:chris.plummer@oracle.com" target="_blank">chris.plummer@oracle.com</a>><br>
<b>Cc: </b><a href="mailto:dholmes@openjdk.org" target="_blank">dholmes@openjdk.org</a>
<<a href="mailto:dholmes@openjdk.org" target="_blank">dholmes@openjdk.org</a>>,
<a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a>
<<a href="mailto:loom-dev@openjdk.org" target="_blank">loom-dev@openjdk.org</a>>,
<a href="mailto:sspitsyn@openjdk.org" target="_blank">sspitsyn@openjdk.org</a>
<<a href="mailto:sspitsyn@openjdk.org" target="_blank">sspitsyn@openjdk.org</a>><br>
<b>Subject: </b>Re: JDK-8334085:
Cannot reproduce failing test</span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">I see, in
that case Serguei would you want
to still own this JBS or would you
be OK if I try to have a look at
it ?</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11pt"> </span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:11pt">Iñigo</span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11pt">El vie,
12 jul 2024, 19:11, Chris
Plummer <<a href="mailto:chris.plummer@oracle.com" target="_blank">chris.plummer@oracle.com</a>>
escribió:</span></p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><span style="font-size:11pt">Failures
are very intermittent. We last
saw a failure in our CI
testing <br>
on 2024-07-03. What command
are you using to run the test?<br>
<br>
Chris<br>
<br>
On 7/12/24 2:34 AM, Iñigo
Mediavilla wrote:<br>
> Hello,<br>
><br>
> While looking at possible
JBS tickets to work on, I saw
JDK-8334085 <br>
> where an assertion was
reported to be failing for the
<br>
> GetOwnedMonitorInfoTest.
Before I even asked around to
wonder if this <br>
> issue was already being
looked at, I tried to
reproduce the failure <br>
> locally, but I don't
manage to make the test fail.
Is this still an <br>
> issue in JDK-24 ? David
can you still reproduce the
failing test ?<br>
><br>
> Best<br>
><br>
> Íñigo Mediavilla Saiz<br>
><br>
></span></p>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div>