RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional

[Doerr, Martin]

Hi Gustavo,

Looks good for the case UseRTMXendForLockBusy is active (which is default).

If this flag is deactivated, we use tabort if we see the object locked so your change prevents retrying the transaction in this case.
I guess this was not intended?

Thanks and best regards,
Martin


-----Original Message-----
From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] 
Sent: Montag, 25. Juni 2018 10:24
To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-dev at openjdk.java.net
Cc: ppc-aix-port-dev at openjdk.java.net
Subject: RFR(s): 8205580: PPC64: RTM: Don't retry lock on abort if abort was intentional

Hi,

Could the following change be reviewed please?

bug   : https://bugs.openjdk.java.net/browse/JDK-8205580
webrev: http://cr.openjdk.java.net/~gromero/8205580/v1/

It changes the behavior of rtm_retry_lock_on_abort() by avoiding retry if abort
was a deliberate abort, i.e. caused by a 'tabort r0' instruction.

On Intel bit 1 in abort_status_Reg (which communicates the abort status) is
always clear when a 'xabort 0' instruction is executed in order to inform that a
transactional retry /can not/ succeed on retry. So rtm_retry_lock_on_abort() on
Intel, on finding bit 1 clear in abort_status_Reg, skips the retry (don't
retry).

Currently on Power rtm_retry_lock_on_abort() is just checking the persistent bit
(if set => skip) which /is not set/ by 'tabort r0'. Hence
rtm_retry_lock_on_abort() does retry to lock on an intentional abort caused by
'tabort'. It leads, for instance when -XX:RTMRetryCount=1, to the following
discrepancy between Intel and Power regarding the number of retries/aborts:

[Power]
# rtm locks total (estimated): 3
# rtm lock aborts  : 3
# rtm lock aborts 0: 3
# rtm lock aborts 1: 3
# rtm lock aborts 2: 0
# rtm lock aborts 3: 0
# rtm lock aborts 4: 0
# rtm lock aborts 5: 0

[Intel]
# rtm locks total (estimated): 2
# rtm lock aborts  : 2
# rtm lock aborts 0: 2
# rtm lock aborts 1: 2
# rtm lock aborts 2: 0
# rtm lock aborts 3: 0
# rtm lock aborts 4: 0
# rtm lock aborts 5: 0

So for -XX:RTMRetryCount=X:
on Power the number of aborts is: X*2+1 [1 first failure + 1 rtm_retry_lock_on_abort() + 1 rtm_retry_lock_on_busy()];
on Intel the number of aborts is: X+1   [1 first failure + 1 rtm_retry_lock_on_busy()]

This change fixes that discrepancy by using bit "Abort" in TEXASR register
(abort_status_Reg) that tells if a transaction was aborted due to a 'tabort'
instruction and skip the retry if such a bit is set.

It fixes the following tests:

+Passed: compiler/rtm/locking/TestRTMRetryCount.java
+Passed: compiler/rtm/locking/TestRTMAbortThreshold.java


Thank you and best regards,
Gustavo