RFR: JDK-8156959: compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java fails with exit 134

[Jiangli Zhou]

Hi Coleen,

Thanks for the review!

Jiangli

> On Jul 26, 2016, at 2:04 PM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> 
> 
> This analysis and fix look good.
> Coleen
> 
> On 7/25/16 7:04 PM, Jiangli Zhou wrote:
>> Please review the following webrev for JDK-8156959 <https://bugs.openjdk.java.net/browse/JDK-8156959> fix.
>> 
>>   http://cr.openjdk.java.net/~jiangli/8156959/webrev.00/
>> 
>> The SensorInfo::has_pending_requests() is not thread safe. It tests '_pending_trigger_count > 0 || _pending_clear_count > 0’. In rare cases, there is a race condition in which the check done by the service thread might return ‘false’ incorrectly while _pending_trigger_count is incremented to 1 and _pending_clear_count is reset to 0 by other thread. In that case, the  'assert(has_pending_requests(), "Must have pending request”)’ in SensorInfo::process_pending_requests() becomes invalid. The fix removes the invalid assert.
>> 
>> As _pending_trigger_count can only be decremented by the service thread and all other threads can only increment the _pending_trigger_count, the race condition issue of SensorInfo::has_pending_requests() is harmless in other usages. If the service thread fails to catch the pending request (when has_pending_requests() returns false incorrectly), it can catch the it in the next iteration. Please see the JDK-8156959 <https://bugs.openjdk.java.net/browse/JDK-8156959> for detailed analysis.
>> 
>> Test: JPRT and RBT hotspot_all.
>> 
>> Thanks,
>> Jiangli
>> 
>