> On 14 nov 2014, at 09:03, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 13/11/2014 13:56, Mikael Auno wrote: >> Hi, >> >> Could I please get a review of this addition of SVC tests to JPRT submit >> jobs. So far, I'm only adding JDI tests as those are the only ones I >> have completed code coverage analysis on to determine the best subset to >> add. The other areas will be added too, but I'm adding these now to get >> the ball rolling asap. >> >> I've run these through JPRT once already without failures and have got >> two more runs in the pipe. I've also looked through the history for >> these tests and found that they do not have any known instabilities to >> worry about. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8064799 >> Webrev: http://cr.openjdk.java.net/~miauno/8064799/webrev.00/ >> >> > This doesn't look very maintainable. If we are adding *_sanity groups then > would be better to move them to their own section of the file so that they > are in the middle of the main grouping of the tests? Also I think we should > avoid list individual tests if we can, would it be better to leave out JDI > until your analysis is completed?
So the goal here has been to increase the test coverage of hotspot jprt push jobs, but with a limited impact on execution time. This is all to make sure hotspot changes do no break serviceability features. While it would be great to run all tests at all times, we don’t have time for that. Mikael has been doing code coverage analysis to find the subset of test that provides the biggest bang for the buck. Starting with JDI is as good as any place to start. I agree that listing individual tests is not particularly appealing, but I don’t see many other options. We could possibly use @key tags to select the tests but there isn’t much support in makefiles and jprt for that if I recall. We could use sub-folders, but that quickly gets out of hand. We could move the _sanity lists to one place in the file to make it easier to see the rest. /Staffan
