<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<div class="moz-cite-prefix">On 7/23/24 4:38 PM, Iñigo Mediavilla
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CA+wBRWC3d73ZWBs8rg8RDicPSMuFAU70pKtN5-pQsfKDpYnM1w@mail.gmail.com">
<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>
</div>
</div>
</blockquote>
Right.<br>
<br>
<blockquote type="cite" cite="mid:CA+wBRWC3d73ZWBs8rg8RDicPSMuFAU70pKtN5-pQsfKDpYnM1w@mail.gmail.com">
<div dir="ltr">
<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>
</div>
</div>
</blockquote>
There is also ObjectLocker which is used to acquire a Java monitor
from inside the VM. Also note that the counter can be modified
during deoptimization if we need to relock objects for which
synchronization was eliminated.<br>
<br>
Patricio<br>
<blockquote type="cite" cite="mid:CA+wBRWC3d73ZWBs8rg8RDicPSMuFAU70pKtN5-pQsfKDpYnM1w@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">chris.plummer@oracle.com</a>><br>
<b>Cc: </b><a href="mailto:dholmes@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dholmes@openjdk.org</a>
<<a href="mailto:dholmes@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dholmes@openjdk.org</a>>,
<a href="mailto:loom-dev@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">loom-dev@openjdk.org</a>
<<a href="mailto:loom-dev@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">loom-dev@openjdk.org</a>>,
<a href="mailto:sspitsyn@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">sspitsyn@openjdk.org</a>
<<a href="mailto:sspitsyn@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">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>
</blockquote>
<br>
</body>
</html>