RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes)
mikael.auno at oracle.com
Fri Jan 30 18:01:50 UTC 2015
I found an issue on Windows. DCMD output has Unix newlines even on
Windows (and actually mixed Unix and Windows newlines when running
through jcmd), so I've updated OutputAnalyzer.asLines() to split on
"(\\r\\n|\\n|\\r)" instead of line.separator. I've also added better
debug output in CodeCacheTest.java.
On 2015-01-30 10:44, Mikael Auno wrote:
> 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