RFR(S): 8207211: [TESTBUG] Remove excessive output from CDS/AppCDS tests

Ioi Lam ioi.lam at oracle.com
Wed Aug 22 18:23:38 UTC 2018


Hi Calvin,

GCDuringDump.java
GCDuringDumpTransformer.java

How about leaving the gcLog like this, so it's easy to debug any future 
failureswith "jtreg -Dtest.cds.verbose.gc=true ..."

    String gcLog = Boolean.getBoolean("test.cds.verbose.gc")?
"-Xlog:gc*=info,gc+region=trace,gc+alloc+region=debug"
        : "-showversion";

CDSTestUtils.java:

     static int count = 0;
     private static int getNextCount() {
         return count++;
     }

Maybe rename to logCounter and getNextLogCounter?

The rest looks good. No need for new webrev for the above suggestions.

Thanks
- Ioi

On 8/22/18 9:46 AM, Calvin Cheung wrote:
> Hi Ioi,
>
> Thanks for your suggestions.
> Updated webrev:
>     http://cr.openjdk.java.net/~ccheung/8207211/webrev.01/
>
> I've reverted the following change in @run:
>     @run main/othervm -Dtest.cds.copy.child.stdout=false
> The number of modified files is much less than in webrev.00.
>
> New changes in CDSTestUtils.java per your suggestions.
>
> I've rerun hs-tier 1,2,3 tests with no new failures.
>
> thanks,
> Calvin
>
> On 8/21/18, 2:38 PM, Ioi Lam wrote:
>> Hi Calvin,
>>
>> I have a few suggestions:
>>
>> 1. Using -Dtest.cds.copy.child.stdout would require "@run 
>> main/othervm". This is slower than "@run", which can use agentvm to 
>> avoid spawning new JVM processes.
>>
>> 2. I think the default should be false, since the stdout is already 
>> logged in files. We can allow the user to override this using "jtreg 
>> -Dtest.cds.copy.child.stdout=true ...."
>>
>>     class CDSTestUtils {
>>         // By default, stdout of child processes are logged in files 
>> such as
>>         // <testname>-0000-exec.stdout. If you want to also include 
>> the stdout
>>         // inside jtr files, you can override this in the jtreg 
>> command line like
>>         // "jtreg -Dtest.cds.copy.child.stdout=true ...."
>>        private static boolean copyChildStdoutToMainStdout =
>>             Boolean.getBoolean("test.cds.copy.child.stdout");
>>
>> 3. CDSTestUtils.executeAndLog should save files with different names 
>> (e.g., with a counter). Today, tests that dump and execute multiple 
>> times end up saving only one dump.stdout and one exec.stdout files, 
>> so older logs are lost.
>>
>> It should also print out the name of the file, like
>>
>>     logging stdout to IncompatibleOptions-0000-exec.stdout
>>
>> Having a 4-digit, 0-prefixed counter should make it easy to find the 
>> file you're looking for.
>>
>> Thanks
>> - Ioi
>>
>>
>>
>> On 8/21/18 11:39 AM, Calvin Cheung wrote:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8207211
>>>
>>> webrev: http://cr.openjdk.java.net/~ccheung/8207211/webrev.00/
>>>
>>> For the tests which generate a lot of output, I used the 
>>> -Dtest.cds.copy.child.stdout=false property to reduce the output to 
>>> the main stdout. The output is still being captured in 
>>> <testname>-dump.stdout (for dump time) and <testname>-exec.stdout 
>>> (for run time).
>>>
>>> In some tests which don't require class loading output, I've simply 
>>> removed the -verbose:class or -Xlog:class+load option.
>>>
>>> Testing: hs-tier{1,2,3}
>>>
>>> thanks,
>>> Calvin
>>



More information about the hotspot-runtime-dev mailing list