JDK-8334085: Cannot reproduce failing test

[Iñigo Mediavilla]

Hello again,

I'm struggling to understanding how the value can be something other than
zero:

In the JBS ticket the error happened for (bsd-amd64) so I'm checking the
code in :

https://github.com/openjdk/jdk/blob/38a578d547f39c3637d97f5e0242f4a69f3bbb31/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1624

In that code, I see the call to thaw being done almost immediately after
the call to `fill_continuation_entry` that sets the value of
`held_monitor_count` to zero.

I'm guessing that it can be some kind of race condition, but I can't think
of which other thread could be having an impact on the `held_monitor_count`
for our JavaThread.

>> What command are you using to run the test?

Sorry Chris, I forgot to answer your question. I'm running the following
command:

make run-test
TEST=test/hotspot/jtreg/serviceability/jvmti/GetOwnedMonitorInfo/GetOwnedMonitorInfoTest.java
JTREG_TEST_THREAD_FACTORY=Virtual JTREG_REPEAT_COUNT=100

Cheers

Íñigo



On Tue, Jul 16, 2024 at 11:01 AM Iñigo Mediavilla <imediava at gmail.com>
wrote:

> Thanks Alan,
>
> >> Note that this code has changed significantly in the loom repo and the
> assert that is triggered in main line doesn't exist in the new code.
>
> My assumption is that:
>
> - In the main line the assertion should hold because we don't unmount a
> virtual thread during blocking operations (we pin it to the carrier and
> park the thread)
> - In loom the assertion has been removed because there are changes like
> commit (756743da) that will make it possible for a thread to be unmounted
> while holding a lock.
>
> Can you confirm if this is correct ?
>
> Íñigo
>
>
> On Sat, Jul 13, 2024 at 10:27 AM Alan Bateman <Alan.Bateman at oracle.com>
> wrote:
>
>> On 13/07/2024 08:07, Iñigo Mediavilla wrote:
>>
>> 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 ?
>>
>> Debug build and JTREG_TEST_THREAD_FACTORY=Virtual. Note that this code
>> has changed significantly in the loom repo and the assert that is triggered
>> in main line doesn't exist in the new code. -Alan.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240718/9b2ed180/attachment.htm>