RFR(XS): 8204135: jtreg: Fix failing RTM test TestUseRTMXendForLockBusy
gromero at linux.vnet.ibm.com
Thu May 31 02:04:53 UTC 2018
Could the following change be reviewed please?
bug : https://bugs.openjdk.java.net/browse/JDK-8204135
It fixes currently failing RTM test "TestUseRTMXendForLockBusy" by changing
in which cases UseRTMForStackLocks flags must be enabled/disabled.
I could not track down on the timeline when exactly that test stopped to
pass, however my understanding is that if inflateMonitor is 'false' that
should /not/ imply that UseRTMForStackLocks is also 'false'. Thus I
understand that for this particular test if inflated monitors are used,
then UseRTMForStackLocks has to be disabled, i.e. 'false'. On the other
hand, if inflated monitors are /not/ used, then UseRTMForStackLocks must be
Currently the test is failing for the following cases where inflateMonitor
is 'false', because it implies that UseRTMForStackLocks is disabled and so
no abort statistics is generated (which is correct from the JVM's
// stack lock, xabort on lock busy
// stack lock, xend on lock busy
In other words, "stack lock" case should imply UseRTMForStackLocks = 'true',
// inflated lock, xabort on lock busy
// inflated lock, xend on lock busy
are not failing because UseRTMForStackLocks = 'true' and they will generate
proper abort statistics when +UseRTMXendForLockBusy ('xend' is used to
finish the transaction) or when -UseRTMXendForLockBusy ('xabort' is used
to finish the transaction).
So, in summing up: (a) inflated lock cases are not being tested correctly
(since UseRTMForStackLocks is always enabled) and (b) stack lock cases are
failing because UseRTMForStackLocks is always disabled.
@Igor, it's a long time ago, but maybe you recall some details on that
More information about the hotspot-compiler-dev