[11] RTM tests fail

[Christian Thalinger]

> On Jun 25, 2018, at 8:49 AM, Gustavo Romero <gromero at linux.vnet.ibm.com> wrote:
> 
> On 06/25/2018 09:46 AM, Lindenmaier, Goetz wrote:
>>>> Did you check with or without these fixes?
>>> 
>>> Without, unfortunately.  Are all of the failures fixed now (in jdk-11+19)?
>> I don't know, our machines do not have RTM, only our Power ones do.
>> But I think Gustavo Romero from IBM claimed so.
> 
> Yup, after the three fixes Goetz mentioned all RTM tests must pass on Intel.

Ok, I’ll get back to you…

> 
> 
> Regards,
> Gustavo
> 
>> Best regards,
>>  Goetz.
>>> 
>>>> 
>>>> Best regards,
>>>>  Goetz.
>>>> 
>>>>> -----Original Message-----
>>>>> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-
>>>>> bounces at openjdk.java.net] On Behalf Of Christian Thalinger
>>>>> Sent: Montag, 25. Juni 2018 14:17
>>>>> To: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>>>>> Subject: [11] RTM tests fail
>>>>> 
>>>>> Hi!  Is anyone running the compiler/rtm/ tests on a machine that actually
>>>>> supports RTM?
>>>>> 
>>>>> Every time one of our nightly jobs ends up on a machine that supports
>>> RTM a
>>>>> bunch of locking tests and the print test fail:
>>>>> 
>>>>> 	• compiler/rtm/locking/TestRTMAbortRatio.java.TestRTMAbortRatio
>>>>> 	•
>>>>> 
>>> compiler/rtm/locking/TestRTMAbortThreshold.java.TestRTMAbortThreshold
>>>>> 	•
>>>>> 
>>> compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java.TestRTMAfterNonR
>>>>> TMDeopt
>>>>> 	•
>>>>> 
>>> compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeopt
>>>>> OnHighAbortRatio
>>>>> 	•
>>>>> 
>>> compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeopt
>>>>> OnLowAbortRatio
>>>>> 	•
>>>>> 
>>> compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThresh
>>>>> old
>>>>> 	•
>>>>> 
>>> compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXend
>>>>> ForLockBusy
>>>>> 	•
>>>>> 
>>> compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreci
>>>>> seRTMLockingStatistics
>>>>> 
>>>>> Exceptions look like this (for all the failures above in order):
>>>>> 
>>>>> java.lang.RuntimeException: Actual abort ratio (10000) should lower or
>>> equal
>>>>> to specified (100).: expected that 10000 <= 100
>>>>> 
>>>>> java.lang.RuntimeException: Expected that method with rtm lock elision
>>> was
>>>>> deoptimized after 1 lock attempts: expected 3320 to equal 1
>>>>> 
>>>>> java.lang.RuntimeException: Two uncommon traps with reason
>>>>> rtm_state_change should be fired.: expected 0 to equal 2
>>>>> 
>>>>> java.lang.RuntimeException: Expected to get only one deoptimization due
>>> to
>>>>> rtm state change: expected 0 to equal 1
>>>>> 
>>>>> java.lang.RuntimeException: Expected to get only one deoptimization due
>>> to
>>>>> rtm state change: expected 0 to equal 1
>>>>> 
>>>>> java.lang.RuntimeException: There should be exactly one statistics entry
>>>>> corresponding to ProfileRTM state.: expected null to not equal null
>>>>> 
>>>>> java.lang.RuntimeException: VM output should contain exactly one rtm
>>>>> locking statistics entry for method compiler.testlibrary.rtm.BusyLock::test:
>>>>> expected 0 to equal 1
>>>>> 
>>>>> java.lang.RuntimeException: RTM locking statistics should contain non
>>> zero
>>>>> aborts count for abort reason 0: expected 0 > 0
>>>>> 
>>>>> Since these tests are not excluded I have to assume that either (a) they
>>> work
>>>>> for you (really?) or (b) that Oracle (or someone else) doesn’t have
>>> machines
>>>>> that support RTM.
>