[11] RTM tests fail

Christian Thalinger cthalinger at twitter.com
Mon Jun 25 12:41:31 UTC 2018



> On Jun 25, 2018, at 8:40 AM, Gustavo Romero <gromero at linux.vnet.ibm.com> wrote:
> 
> Hi Christian,
> 
> I'm facing major issues with infra in our lab  right now.
> 
> Once it gets solved I'll list the state I get on our lab before "JDK-8204134".
> 
> But given your list I would say "JDK-8204134" is exactly the fix missing in your
> case.

Excellent, thank you.  I will update our copy and let you know if everything is passing then.

> 
> 
> Regards,
> Gustavo
> 
> On 06/25/2018 09:26 AM, Christian Thalinger wrote:
>>> On Jun 25, 2018, at 8:16 AM, Christian Thalinger <cthalinger at twitter.com <mailto:cthalinger at twitter.com>> wrote:
>>> 
>>> 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.TestRTMAfterNonRTMDeopt
>>> • compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java.TestRTMDeoptOnHighAbortRatio
>>> • compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java.TestRTMDeoptOnLowAbortRatio
>>> • compiler/rtm/locking/TestRTMLockingThreshold.java.TestRTMLockingThreshold
>>> • compiler/rtm/locking/TestUseRTMXendForLockBusy.java.TestUseRTMXendForLockBusy
>>> • compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java.TestPrintPreciseRTMLockingStatistics
>>> 
>>> 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.
>> Was this maybe fixed by https://bugs.openjdk.java.net/browse/JDK-8204134?  It’s hard to tell because the bug doesn’t say how the tests failed.
> 



More information about the hotspot-compiler-dev mailing list