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

[Filipp Zhinkin]

Vladimir, thank you.

Regards,
Filipp.

----- Original Message -----
From: vladimir.kozlov at oracle.com
To: hotspot-compiler-dev at openjdk.java.net
Sent: Tuesday, December 30, 2014 9:43:28 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

Good.

Thanks,
Vladimir

On 12/30/14 10:14 AM, Filipp Zhinkin wrote:
> 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.
>>