RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes)
erik.gahlin at oracle.com
Fri Jan 30 13:20:10 UTC 2015
Mikael Auno skrev 2015-01-30 10:44:
> Hi, could I please some reviews for this test port?
> Issues: https://bugs.openjdk.java.net/browse/JDK-8071908
> Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/
> Read on for the rationale on a few questions that might arise.
> * Why two issues?
> These changes are mainly a port of the Diagnostic Command (DCMD) tests
> and corresponding framework/utility classes from an internal (non-open)
> test framework to jtreg. The reason for the two issues is that the
> changes depend on a few modifications to testlibrary that are available
> in jdk/test but not yet in hotspot/test, as well as a small new addition
> to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD
> tests). To keep the history as clean and coherent as possible, those
> changes will go in under JDK-8071909 while the new tests and
> DCMD-related additions to testlibrary go in under JDK-8071908.
> * Isn't there already utility classes for calling Diagnostic Commands?
> The main idea with the new utility classes in testlibrary is to provide
> a single interface to call Diagnostic Commands from tests, regardless of
> the transport used (e.g. jcmd or JMX). There are a few tests scattered
> around jdk/test and hotspot/test today that already utilize Diagnostic
> Commands in some way, but they either use different utility classes for
> this in different places or just do it directly in the test. Also, some
> of these utility classes or tests go through jcmd and some through JMX
> (most often without any real requirement for one transport over the
> other in the test). All this means that there are, today, numerous
> different implementations for calling Diagnostic Commands, and
> consequently a lot of code duplication. These utility classes are meant
> to replace all of these implementations, and with a single interface
> regardless of the transport at that.
> * You've missed this or that test using one of the existing utility classes!
> This is "by design". In order to keep the change at a more manageable
> size and to get the core of this change in sooner, we've chosen to do
> this transition in multiple steps. The first of those steps is what is
> in this review request; the core utility classes, the tests ported from
> the internal test framework and the adaption of the tests already in
> hotspot/test/serviceability/dcmd (since they happened to reside in the
> directory where we wanted to put the ported tests). When this is
> integrated and have gone a few rounds through nightly testing, the
> adaption of other tests in hotspot/test will follow, and after that
More information about the hotspot-runtime-dev