RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization
filipp.zhinkin at oracle.com
Mon Dec 29 20:27:08 UTC 2014
thank you for looking at it.
The second thread (which is started in line 75) enters the monitor first.
It is guaranteed by a barrier.
When the barrier passed, the second thread calls wait() on the monitor
and thus inflate and release it.
The first thread then may enter the monitor in line 78.
----- Original Message -----
From: vladimir.kozlov at oracle.com
To: hotspot-compiler-dev at openjdk.java.net
Sent: Monday, December 29, 2014 10:37:16 PM GMT +03:00 Iraq
Subject: Re:  RFR (M): 8050486: compiler/rtm/ tests fail due to monitor deflation at safepoint synchronization
I don't understand how you expect progress in lines 78-83 in
AbortProvoker.java when second thread keeps lock of 'monitor'.
synchronized (monitor) at the line 78 should wait until second thread
release it so you will never reach line 83.
I would suggest to lunch third thread to inflate monitor and use main
thread to see the state.
On 12/29/14 8:35 AM, Filipp Zhinkin wrote:
> Hi all,
> please review a fix for JDK-8050486.
> Following issues cause compiler/rtm/ tests failures
> when safepoint sync happened in the middle of test run:
> - monitors that expected to be inflated are deflated;
> - monitors that expected to be lightweight stack-locks are inflated.
> In order to solve the first issue inflation-forcing algorithm
> was modified to wait forever on a monitor that should be inflated.
> The second issue is resolved by explicit monitor state checks that
> force deflation in case when monitor is inflated, but it should not.
> This fix depends on 8068272:
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8050486
> Webrev: http://cr.openjdk.java.net/~fzhinkin/8050486/webrev.00/
> Testing: on host w/ HSW CPU, JPRT, automated on hosts w/ HSW CPU.
More information about the hotspot-compiler-dev