RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases
filipp.zhinkin at oracle.com
Tue Dec 30 18:14:52 UTC 2014
I've added appropriate comment:
Well, if such intrinsic will be added,
then we can replace Unsafe::addressSize by any
other native method call.
----- Original Message -----
From: vladimir.kozlov at oracle.com
To: hotspot-compiler-dev at openjdk.java.net
Sent: Tuesday, December 30, 2014 8:25:57 PM GMT +03:00 Iraq
Subject: Re:  RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases
Please, add comment that abort is caused by jni call to addressSize(). I thought we have intrinsic for that method and
abort will not happen. And if we add such intrinsic the test will fail.
On 12/30/14 12:42 AM, Filipp Zhinkin wrote:
> Hi all,
> please review a fix for 8068269.
> A few RTM tests assert on non-zero locks count in
> PrintPreciseRTMLockingStatistics entries, but at the same time
> these tests use RTMTotalCountIncrRate > 1.
> If RTMTotalCountIncrRate > 1, then locks count will be incremented
> only when (rdtsc() & (RTMTotalCountIncrRate - 1) == 0) (*).
> We may never met condition (*) during a short test run and
> in such case test will fail.
> An there is one more rare case: when we didn't met (*) and
> there were no transactional execution abortions.
> In such case counters will contain zero, JVM will consider
> it unused and won't print it out.
> To fix these issues assertions on non-zero locks count
> were removed for cases where RTMTotalCountIncrRate > 1
> and in order to avoid issue with zero counters affected
> test is now forcing one transactional execution abort.
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8068269
> Webrev: http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.01/
> Testing: manual & automaed on host w/ HSW CPU, JPRT
More information about the hotspot-compiler-dev