RFR (S) 7014552: gc/lock/jni/jnilockXXX works too slow on 1-processor machine

[Mikael Gerdin]

Thanks
Bengt, Erik and John for the reviews.

I'll go ahead and push this tomorrow.
/Mikael

On 2013-03-26 18:31, John Cuthbertson wrote:
> Hi Mikael,
>
> The changes look good to me. Ship it.
>
> JohnC
>
> On 3/21/2013 9:24 AM, Mikael Gerdin wrote:
>> Hi
>>
>> Please review the following change:
>>
>> When running a stress test that is repeatedly blocking GC from
>> triggering through the normal path we may get stuck in the allocation
>> path and stay in the allocation loop forever.
>>
>> In this case the problem seems to be that if some threads are
>> repeatedly entering and leaving JNI critical regions and thereby
>> stressing the GC_Locker an allocating thread may get stuck in the
>> allocation loop and never realize that the pending allocation is
>> impossible due to heap usage.
>>
>> My suggested fix is to limit the amount of times we try to start GCs
>> and then simply give up and return NULL and fail the allocation,
>> thereby causing the caller to throw an OOME.
>>
>> Note that every time the counter is incremented because we return from
>> GC_Locker::stall_until_clear() the thread unlocking the GC_Locker has
>> actually triggered a GC. So we're not giving up without a fight.
>>
>> Public bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7014552
>> JIRA:       https://jbs.oracle.com/bugs/browse/JDK-7014552
>> Webrev:     http://cr.openjdk.java.net/~mgerdin/7014552/webrev.0/
>>
>> Thanks
>> /Mikael
>