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