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

Ioi Lam ioi.lam at oracle.com
Tue Aug 21 21:38:00 UTC 2018


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