RFR: 8026047: [TESTBUG] add regression test for DisableExplicitGC flag

[Bengt Rutisson]

Hi Michail,

I like the idea of using the GarbageCollectionMXBean!

However, I am not too happy about the test waiting for 20 seconds. 
Especially since you have the failing test which will actually wait for 
20 seconds.

Instead I would suggest to just use the collection count. Attaching a 
version of the test that use that instead. What do you think about this 
approach?

Thanks,
Bengt



On 2015-02-25 13:42, Michail Chernov wrote:
> Hi Bengt,
>
> I've rewritten test using JMX. I don't see here any reason to use gc 
> log for testing this flag.
>
> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.02/
>
> It seems better solution because it doesn't depend on used GC or log 
> message format.
>
> Tested locally with JDK 9 b51 using several GC. Tested using Aurora on 
> all platforms.
>
> Thanks,
> Michail
>
> On 12.02.2015 17:07, Bengt Rutisson wrote:
>>
>> Hi Michail,
>>
>> On 11/02/15 16:33, Michail Chernov wrote:
>>> Hi Bengt,
>>>
>>> Test works with all options passed to jtreg during testing ( see 
>>> line 97         vmOpts.addAll(0, Utils.getVmOptions());). Doesn't 
>>> need to check all GC's, it will be done during nightly.
>>
>> Ah. I see that now.
>>
>>>
>>> 44     public final static String[] PARALLEL_GC_OPTIONS = 
>>> {"UseParallelGC", "UseParallelOldGC"};
>>> Here is defined special options. If define one of these options - 
>>> will be used other pattern to match output.
>>
>> Right.
>>
>>>
>>> But it seems to me a little bit wrong. I've checked output of GC log 
>>> with different GCs and ExplicitGCInvokesConcurrent. Message "Full GC 
>>> (System.gc())" does not appear only in case of using G1 or CMS with 
>>> ExplicitGCInvokesConcurrent=true. Will fix it.
>>
>> OK.
>>
>> My main point was that I think the whole structure of the test is 
>> different than how we usually write tests that verify the log output. 
>> I would prefer if the tests look similar. Would you mind re-writing 
>> the test to look like the other tests.
>>
>> I much prefer that you explicitly start with the GCs you want to test 
>> than that you use the WhiteBox API to find out which GC you are running.
>>
>> I'm having a similar discussion with Dima who recently invented yet 
>> another way to parse the GC log output from tests. I think it gets 
>> very hard to read the tests when they do the same thing in different 
>> ways.
>>
>> Thanks,
>> Bengt
>>>
>>> Thanks,
>>> Michail
>>> On 11.02.2015 16:15, Bengt Rutisson wrote:
>>>>
>>>> Hi Michail,
>>>>
>>>> On 11/02/15 13:55, Michail Chernov wrote:
>>>>> Hi,
>>>>>
>>>>> Still hoping for review!
>>>>
>>>> Sorry for being so late in looking at this.
>>>>
>>>> A couple of questions:
>>>>
>>>> Why does the test only test the parallel GC? DisableExplicitGC is 
>>>> valid for all GCs.
>>>>
>>>> What do you think about writing this test similar to other tests 
>>>> that validate the output from the GC logging? Here's an example:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/hs-gc/hotspot/file/566574421b40/test/gc/g1/TestGCLogMessages.java 
>>>>
>>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>>
>>>>> Thanks,
>>>>> Michail
>>>>>
>>>>> On 05.02.2015 21:05, Michail Chernov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Still waiting for reviews!
>>>>>>
>>>>>> Thanks,
>>>>>> Michail
>>>>>>
>>>>>> On 03.02.2015 20:12, Michail Chernov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Can someone take a look on these changes, please?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Michail
>>>>>>>
>>>>>>> On 30.01.2015 18:33, Michail Chernov wrote:
>>>>>>>> Hi Leonid,
>>>>>>>>
>>>>>>>> Issues were fixed:
>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.01/
>>>>>>>>
>>>>>>>> Now all testcases are executed  from the same VM.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Michail
>>>>>>>>
>>>>>>>> On 28.01.2015 18:28, Leonid Mesnik wrote:
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> Why is it needed to start VM twice for each test. It is very 
>>>>>>>>> expensive especially for low-end devices.
>>>>>>>>>
>>>>>>>>> Is it possible to have driver which starts VM several times 
>>>>>>>>> with different combinations of options and check it 
>>>>>>>>> output/exit code etc? Also it would be much easier to read 
>>>>>>>>> such test.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Leonid
>>>>>>>>>
>>>>>>>>> On 27.01.2015 18:35, Michail Chernov wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please review the fix with new test for DisableExplicitGC VM 
>>>>>>>>>> flag.
>>>>>>>>>>
>>>>>>>>>> Webrev: 
>>>>>>>>>> http://cr.openjdk.java.net/~eistepan/~mchernov/8026047/webrev.00/ 
>>>>>>>>>>
>>>>>>>>>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8026047
>>>>>>>>>>
>>>>>>>>>> There is one scenario with 6 parameters combinations.
>>>>>>>>>>
>>>>>>>>>> 1,2,3 scenarios test default value for DisableExplicitGC, 
>>>>>>>>>> DisableExplicitGC=true and DisableExplicitGC=false
>>>>>>>>>> 4,5,6 scenarios check how VM works when VM changes 
>>>>>>>>>> DisableExplicitGC flag using WhiteBox.
>>>>>>>>>>
>>>>>>>>>> Test tries to call System.gc() and check that VM puts message 
>>>>>>>>>> to stdout. After (in case of 4,5,6 scenarios) test tries to 
>>>>>>>>>> change DisableExplicitGC value and calls System.gc() twice.
>>>>>>>>>>
>>>>>>>>>> Test was executed locally on linux-i586 with all available GC 
>>>>>>>>>> and several GC-related flags. Also it was executed using 
>>>>>>>>>> Aurora on other platforms.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Michail
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestDisableExplicitGC.java
Type: text/x-java
Size: 2239 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150303/6f53fc16/TestDisableExplicitGC.java>