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

[Calvin Cheung]

Hi Ioi,

I've made the additional changes and will do more testing before push.
Just one comment below.

thanks,
Calvin

On 8/22/18, 11:23 AM, Ioi Lam wrote:
> Hi Calvin,
>
> GCDuringDump.java
> GCDuringDumpTransformer.java
I think you were referring to GCSharedStringsDuringDump.java instead of 
GCDuringDumpTransformer.java as there was no gc logging in the latter.
>
> 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
>>>
>