RFR (L): 8024319: Add regression tests on documented GC-related -XX:+Print* options

Bengt Rutisson bengt.rutisson at oracle.com
Thu Jan 22 07:20:46 UTC 2015


Hi Denis,

Not a full review, but I have a question.

It seems like the AbstractPrintGCTest is kind of duplicating what 
ProcessTools already does. Have you considered using 
ProcessTools.createJavaProcessBuilder(..) instead of the @run commands 
to automatically get the process control and log support instead of 
introducing the AbstractPrintGCTest class?

Thanks,
Bengt

On 2015-01-20 16:49, denis kononenko wrote:
> Hi All,
>
> Could you please review new tests on GC-related -XX:Print options.
>
> Webrev link: 
> http://cr.openjdk.java.net/~eistepan/dkononen/8024319/webrev.00/
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8024319
> Testing: automated
> Description:
>
> There is a group of new tests to test the following GC options:
>
> -XX:+-PrintAdaptiveSizePolicy
> -XX:+-PrintGCApplicationConcurrentTime
> -XX:+-PrintGCApplicationStoppedTime
> -XX:+-PrintGCDateStamps
> -XX:+-PrintGCDetails
> -XX:+-PrintGC
> -XX:+-PrintGCTimeStamps
> -XX:+-PrintTenuringDistribution
>
> Each of the tested options has a pair of corresponding tests, one is 
> for testing an enabled option and another for disabled. The tests are 
> simple parsers of GC's logger output and looking for a specific marker 
> corresponding to the tested option. The output is provided by another 
> process which is implemented in GCTask.java. It's necessary because we 
> have to guarantee that GC's log has been completely written and 
> committed to the filesystem before we start analyzing it. The most 
> obvious solution is to politely finish the writing process. Thus the 
> every test spawns an auxiliary process which produces GC's log file, 
> waits for its finish, loads the output and then performs actual 
> testing. These steps are implemented with jtreg's annotations and a 
> helper class which can be found AbstractPrintGCTest.java. This class 
> encapsulates reading GC's log output from the log file and provides 
> that output to the tests.
>
> To get GC's logger working GCTask forces the garbage collecting 
> process. It attempts to consume all memory available to the young 
> generation by creating a lot of unreferenced objects. Sooner or later 
> the garbage collector shall be invoked. In favor of performance the 
> task is implemented to be ran with a small memory size less or equal 
> to 128 megabytes. This is excplicitly specified with -Xmx JVM's option 
> in jtreg's annotations.
>
> Please note that some options work for specific GCs only. To prevent 
> them from being executed against wrong GC jtreg's annotations and 
> groups are used.
>
> Thank you,
> Denis.
>
>
>




More information about the hotspot-gc-dev mailing list