JDK-8334085: Cannot reproduce failing test

[Patricio Chilano Mateo]

Hi Iñigo,

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().

Thanks,
Patricio

On 7/22/24 7:30 AM, Iñigo Mediavilla wrote:
> Hello Serguei,
>
> 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 ?
>
> Based on the DBG output shared in JBS, my understanding is that what 
> happens in the test is the following:
>
> Main                         Thread
> -------------------------   ----------------------------
> 1. acquire java lock
> 2. starting thread
>                                  3. jni call
>                                  4. MonitorContendedEnter
> 5. release java lock
>                                  6. acquire java lock
>                                  7. MonitorContendedEntered
>                                  8. Thread in sync section
>                                  9. release java lock
>                                10. why freeze doesn't pin ?
>
> 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").
>
> Thanks in advance
>
> Íñigo
>
> On Fri, Jul 19, 2024 at 10:41 PM Serguei Spitsyn 
> <serguei.spitsyn at oracle.com> wrote:
>
>     Hi Iñigo,
>
>     Patricio helped to reproduce this issue and also identified the
>     problem (please, see in the bug report).
>     The fix is a one-liner. I’ll post a PR after some mach5 testing.
>
>     Thank you for involvement into this issue!
>
>     Thanks,
>
>     Serguei
>
>     *From: *Iñigo Mediavilla <imediava at gmail.com>
>     *Date: *Saturday, July 13, 2024 at 12:08 AM
>     *To: *Chris Plummer <chris.plummer at oracle.com>
>     *Cc: *dholmes at openjdk.org <dholmes at openjdk.org>,
>     loom-dev at openjdk.org <loom-dev at openjdk.org>, sspitsyn at openjdk.org
>     <sspitsyn at openjdk.org>
>     *Subject: *Re: JDK-8334085: Cannot reproduce failing test
>
>     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 ?
>
>     Iñigo
>
>     El vie, 12 jul 2024, 19:11, Chris Plummer
>     <chris.plummer at oracle.com> escribió:
>
>         Failures are very intermittent. We last saw a failure in our
>         CI testing
>         on 2024-07-03. What command are you using to run the test?
>
>         Chris
>
>         On 7/12/24 2:34 AM, Iñigo Mediavilla wrote:
>         > Hello,
>         >
>         > While looking at possible JBS tickets to work on, I saw
>         JDK-8334085
>         > where an assertion was reported to be failing for the
>         > GetOwnedMonitorInfoTest. Before I even asked around to
>         wonder if this
>         > issue was already being looked at, I tried to reproduce the
>         failure
>         > locally, but I don't manage to make the test fail. Is this
>         still an
>         > issue in JDK-24 ? David can you still reproduce the failing
>         test ?
>         >
>         > Best
>         >
>         > Íñigo Mediavilla Saiz
>         >
>         >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240722/bda5fd82/attachment.htm>