[9] RFR (S): 8068269: RTM tests that assert on non-zero lock statistics are too strict in RTMTotalCountIncrRate > 1 cases

[Filipp Zhinkin]

Hi Vladimir,

I've added appropriate comment:
http://cr.openjdk.java.net/~fzhinkin/8068269/webrev.02/

Well, if such intrinsic will be added,
then we can replace Unsafe::addressSize by any
other native method call.

Thanks,
Filipp.

----- 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: [9] 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.

Thanks,
Vladimir

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
>
> Thanks,
> Filipp.
>