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

Michail Chernov michail.chernov at oracle.com
Tue Mar 3 15:32:44 UTC 2015


Hi Bengt,

I checked run time of test on raspberry-pi and on some solaris host with 
-Xcomp option. On r-pi it works 2.8 seconds, on solaris host it works 
3.5 seconds. I can set NOTIFICATION_DELAY=5 (for example) to speed up 
the test.
Your approach has some cons - it does not check that System.gc() was 
real GC source. In case if we don't check source of GC events, we can 
simplify test more and avoid usage of JMX:

import java.lang.ref.WeakReference;

public class Test{
     public static volatile WeakReference<Object> ref;
     public static Object refObject;
     public static void main(String[] args) {
         ref=new WeakReference<>(new Object());
         refObject=ref.get();
         if ( refObject==null)
             throw new RuntimeException("ERROR! Object was collected 
before GC");
         refObject=null;
         System.gc();
         refObject=ref.get();
         if ( refObject!=null)
             throw new RuntimeException("ERROR! Object was not collected 
during GC");
     }
}

However, this solution does not check the real cause of GC. If this way 
is applicable here, I could use this code for testing DisableExplicitGC 
flag.

Thanks,
Michail

On 03.03.2015 11:02, Bengt Rutisson wrote:
>
> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>




More information about the hotspot-gc-dev mailing list