RFR: 8177968: Add GC stress test TestGCLocker

Erik Helin erik.helin at oracle.com
Tue Apr 18 10:20:05 UTC 2017


On 04/18/2017 12:18 PM, Leonid Mesnik wrote:
> Yes, test looks good. No separate review for adding key is needed.

Thanks!
Erik

> Leonid
>
>
> On 18.04.2017 13:05, Erik Helin wrote:
>> On 04/18/2017 11:30 AM, Leonid Mesnik wrote:
>>> Hi
>>
>> Hey Leonid!
>>
>>> Sorry for late response.
>>
>> No worries, thanks for reviewing :)
>>
>>> Could you please add tag ' @key stress' to the tests. It helps to
>>> exclude them using keywords when only fast tests are going to be run.
>>> I am not sure if it is used right now in the test execution for gc
>>> tests. However it is a good practice and all other gc stress tests are
>>> marked.
>>
>> Sure, will do that before I push. Do you think the test looks good
>> otherwise?
>>
>> Thanks,
>> Erik
>>
>>> Leonid
>>>
>>>
>>> On 18.04.2017 12:22, Erik Helin wrote:
>>>> On 04/12/2017 08:05 AM, Per Liden wrote:
>>>>> Hi Erik,
>>>>>
>>>>> (Re-sending, as Thunderbird crashed on me and it seems that my first
>>>>> reply never made it to the list)
>>>>
>>>> Hey Per,
>>>>
>>>> thanks for reviewing! Please see new version at
>>>> - inc: http://cr.openjdk.java.net/~ehelin/8177968/00-01/
>>>> - full: http://cr.openjdk.java.net/~ehelin/8177968/01/
>>>>
>>>> and comments inline:
>>>>
>>>>> On 2017-04-07 17:48, Erik Helin wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> this patch adds the stress test "TestGCLocker". The test repeatedly
>>>>>> calls GCLocker::lock_critical/unlock_critical (via the JNI functions
>>>>>> GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical) while
>>>>>> concurrently filling up the old gen. Thea idea is to stress the
>>>>>> GCLocker
>>>>>> implementation by quickly entering/leaving critical JNI sections
>>>>>> while
>>>>>> simultaneously allocating objects to fill up the heap in order to
>>>>>> provoke a GC.
>>>>>>
>>>>>> Enhancement:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8177968
>>>>>>
>>>>>> Patch:
>>>>>> http://cr.openjdk.java.net/~ehelin/8177968/00/
>>>>>
>>>>> I did some test runs and it seems the test only provokes the wanted
>>>>> situation in ~20% of the GCs (on my machine at least). Being a stress
>>>>> test, I'd like to propose that we remove the sleep() calls to have it
>>>>> provoke the situation in ~100% of the GCs.
>>>>
>>>> Thanks for taking the code for a spin!
>>>>
>>>>> --- a/test/gc/stress/gclocker/TestGCLocker.java
>>>>> +++ b/test/gc/stress/gclocker/TestGCLocker.java
>>>>> @@ -162,7 +153,6 @@
>>>>>
>>>>>          while (!shouldExit()) {
>>>>>              load();
>>>>> -            ThreadUtils.sleep(100);
>>>>>          }
>>>>>      }
>>>>>  }
>>>>> @@ -175,7 +165,6 @@
>>>>>          byte[] array = new byte[1024 * 1024];
>>>>>          while (!shouldExit()) {
>>>>>              fillWithRandomValues(array);
>>>>> -            ThreadUtils.sleep(10);
>>>>>          }
>>>>>      }
>>>>>  }
>>>>
>>>> Great suggestion, will update the patch.
>>>>
>>>>> Also, the filler function only writes to the first byte, which looks
>>>>> like a bug. Simple fix:
>>>>>
>>>>> --- a/test/gc/stress/gclocker/libTestGCLocker.c
>>>>> +++ b/test/gc/stress/gclocker/libTestGCLocker.c
>>>>> @@ -29,7 +29,7 @@
>>>>>    jbyte* p = (*env)->GetPrimitiveArrayCritical(env, arr, NULL);
>>>>>    jsize i;
>>>>>    for (i = 0; i < size; i++) {
>>>>> -      *p = i % 128;
>>>>> +    p[i] = i % 128;
>>>>>    }
>>>>>    (*env)->ReleasePrimitiveArrayCritical(env, arr, p, 0);
>>>>>  }
>>>>
>>>> Heh, thanks for noticing this :) Reminds me of:
>>>> http://dilbert.com/strip/2001-10-25
>>>>
>>>>> Other than that, looks good!
>>>>
>>>> Thanks!
>>>> Erik
>>>>
>>>>> cheers,
>>>>> Per
>>>>>
>>>>>> Testing:
>>>>>> - JPRT (to ensure libTestGCLocker.c compiles on all platforms)
>>>>>> - make run-test TEST=hotspot/test/gc/stress/gclocker
>>>>>>
>>>>>> Thanks,
>>>>>> Erik
>>>
>


More information about the hotspot-gc-dev mailing list