RFR: JDK-8215568: Refactor SA clhsdb tests to use ClhsdbLauncher
JC Beyler
jcbeyler at google.com
Mon Jan 7 18:42:40 UTC 2019
Hi Jini,
I saw this typo:
http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html
+ List<String> cmds = List.of("printmado -a");
Should it not be printmdo and not printmado? does printmado exist? If it
doesn't how does the test pass (my guess is that we do not catch a
"unexpected command" and that the hashmaps are not finding the keys so they
are not checking the expected/unexpected results; if so perhaps a follow-up
should fix that an unknown command fails a test trying to do that / and
perhaps if the key is not found, the test fails as well?)
Thanks!
Jc
On Tue, Jan 1, 2019 at 9:07 PM Jini George <jini.george at oracle.com> wrote:
> Thank you very much for the review, JC. My comments inline.
>
>
> > I saw this potential issue with one of the test conversions:
> >
> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestPrintMdo.java.udiff.html
> > - It seems like there is a missing "unexpected" strings check here
> no?
> > - The original test was doing
> > -
> > - if (line.contains("missing reason for ")) {
> > - unexpected = new RuntimeException("Unexpected msg:
> > missing reason for ");
> > - break;
> > - }
> >
> > whereas the new test is not seemingly (though
> >
> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java.udiff.html
> > does do it so I think this is an oversight?).
>
> Thank you very much for pointing this out! This was an oversight. I have
> added the unexpected strings check.
>
> >
> > - Also interesting is that the original test was trying to find one
> > of X:
> > - if (line.contains("VirtualCallData") ||
> > - line.contains("CounterData") ||
> > - line.contains("ReceiverTypeData")) {
> > - knownProfileDataTypeFound = true;
> > - }
> >
> > whereas you are now wanting to find all of them. Is that normal/wanted?
>
> I was being extra cautious when I had written this test case in the
> beginning :-). As far as I have seen, the printmdo output does contain
> all of these. (The test passes with 50 repeated runs across all hs tiers
> with the changes -- so I believe it is OK).
>
> I have the new webrev at:
>
> http://cr.openjdk.java.net/~jgeorge/8215568/webrev.01/
>
> I have additionally modified the copyright year to 2019.
>
> Thank you,
> Jini.
>
>
> >
> > The rest looked good to me, though I wish there were a way to not have
> > to change all the strings to be regex friendly but I fail to see how to
> > do that without writing a runCmdWithoutRegexMatcher, which seems
> > overkill :-)
> > Jc
> >
> > On Tue, Dec 18, 2018 at 8:55 PM Jini George <jini.george at oracle.com
> > <mailto:jini.george at oracle.com>> wrote:
> >
> > Hello!
> >
> > Requesting reviews for:
> >
> > http://cr.openjdk.java.net/~jgeorge/8215568/webrev.00/
> >
> > BugID: https://bugs.openjdk.java.net/browse/JDK-8215568
> >
> > No new failures with the SA tests (hs-tiers 1-5) with these changes.
> > The
> > changes here include:
> >
> > * Refactoring the SA tests which test clhsdb commands to use
> > ClhsdbLauncher for uniformity and ease of maintainence.
> > * Testing for regular expressions with shouldMatch rather than
> > shouldContain.
> > * Minor cleanups.
> >
> > Thank you,
> > Jini.
> >
> >
> >
> >
> > --
> >
> > Thanks,
> > Jc
>
--
Thanks,
Jc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190107/ee2a97c5/attachment.html>
More information about the serviceability-dev
mailing list