Hi Alan, I've filed https://bugs.openjdk.java.net/browse/JDK-8181915 <https://bugs.openjdk.java.net/browse/JDK-8181915> to clean up w/ this mess w/ dependencies in testlibrary classes.
just to double check, can I consider this fix and the fixes for tier1[1-2], tier3[3-4] reviewed by you? [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048199.html [2] http://cr.openjdk.java.net/~iignatyev//8181759/webrev.02/index.html [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-June/048165.html [4] http://cr.openjdk.java.net/~iignatyev//8181762/webrev.00/index.html Thanks, -- Igor > On Jun 9, 2017, at 11:50 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > > On 09/06/2017 19:36, Igor Ignatyev wrote: >> Alan, Chris, >> >> it seems I had some problems uploading the webrev, I have reuploaded it to >> the same place -- >> http://cr.openjdk.java.net/~iignatyev//8181761/webrev.02/index.html >> >> -- Igor >> > This mostly looks okay but there are still a few tests being penalized with a > long list of classes in their @build tag. > > Take LotsOfUpdatesTest as example. It's a trivial test to launch a child VM > with `ulimit -n` set to a small value. Its use of ProcessTools to exec the > child is penalized by adding this to its test description: > > 31 * @build jdk.test.lib.Utils > 32 * jdk.test.lib.Asserts > 33 * jdk.test.lib.JDKToolFinder > 34 * jdk.test.lib.JDKToolLauncher > 35 * jdk.test.lib.Platform > 36 * jdk.test.lib.process.* > > Can we get a bug submitted to cull most of this? A lot of our tests needs to > launch child VMs and a simple ProcessTools with minimal dependences would be > preferred. > > -Alan > > >
