<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">just out of curiosity I have removed @build for all jdk.testlibary classes as well and run :tier1, it took approximately the same amount of time[1], the breakdown[2] shows that we spend 70 seconds more on build actions, which is not that big comparing to total execution time.</div><div class=""><div class=""><div class=""><br class=""></div><div class="">-- Igor</div><div class=""><br class=""></div><div class="">[1]</div><div class="">real<span class="Apple-tab-span" style="white-space: pre;"> </span>33m39.697s<br class="">user<span class="Apple-tab-span" style="white-space: pre;"> </span>112m5.722s<br class="">sys<span class="Apple-tab-span" style="white-space: pre;"> </span>6m26.973s</div><div class="">[2] </div><div class="">compile: 903.9<br class="">build: 846.53<br class="">testng: 5515.98<br class="">junit: 674.429<br class="">shell: 885.103<br class="">main: 6973.12<br class="">clean: 0.001<br class="">driver: 9.125</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 2, 2017, at 6:45 PM, Igor Ignatyev <<a href="mailto:igor.ignatyev@oracle.com" class="">igor.ignatyev@oracle.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I have measured how much time it takes to run :tier1 w/ and and w/o the fix which removes @build for jdk.test.lib.** classes[1-2]:</div><div class=""> - w/o 8181391, i.e. w/ @build: real 33m4.624s, user 111m56.758s, sys 6m24.022s. [3] is a breakdown for jtreg actions</div><div class=""><div class=""><div class=""> - w/ 8181391, i.e. w/o @build: real 32m17.259s, user 109m18.236s, sys 6m9.669s. [4] is a breakdown for jtreg actions</div></div><div class="">as you can see there is no much difference in execution time, and the run w/o @build action was even a bit faster. the total time spend on build was lower. hence I'd say removing @build actions does not impact overall execution time. Even if it did, I don't think I'd prefer us to choose isolation and determinism over small performance improvements.</div><div class=""><br class=""></div><div class="">as Ioi and I stated before, removing @build actions did not help in all cases in hotspot. the root cause of this is having @run actions whose target is a class from library, this is identical to have explicit @build action for this class. if this class has dependency on other classes from testlibrary, you can get a testlibrary <span style="white-space: pre-wrap;" class="">split into different locations and as a results NCDFE in runtime due to CODETOOLS-7901986. Fortunately, it is not the case for jdk tests, the only test library class which is used in @run is ClassFileInstaller, which does not have any dependencies. Therefore I think removing explicit @build is a more reliable and clearer way to work around current problems and it does not have a big drawback if any.</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">PS measurements were done on my mac 3.1 GHz Intel Core i7, 16 GB 1867 MHz DDR3, jtreg was run w/ "-conc:8 -agentvm"</span></div><div class=""><br class=""></div><div class="">[1] <a href="http://scaab055.us.oracle.com:9502/vmsqe/home/iignatye/webrev//8181391/webrev.00/index.html" class="">http://scaab055.us.oracle.com:9502/vmsqe/home/iignatye/webrev//8181391/webrev.00/index.html</a></div><div class="">[2] <a href="https://bugs.openjdk.java.net/browse/JDK-8181391" class="">https://bugs.openjdk.java.net/browse/JDK-8181391</a></div><div class="">[3] </div><div class=""><div class="">compile: 826.206</div><div class="">build: 776.955</div><div class="">testng: 5362.58</div><div class="">junit: 640.705</div><div class="">shell: 861.206</div><div class="">main: 6823.19</div><div class="">clean: 0.004</div><div class="">driver: 6.578</div></div><div class="">[4] </div><div class=""><div class="">compile: 829.317</div><div class="">build: 774.904</div><div class="">testng: 5251</div><div class="">junit: 648.888</div><div class="">shell: 852.658</div><div class="">main: 6686.99</div><div class="">clean: 0.002</div><div class="">driver: 5.973</div></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">-- Igor</div><en-clipboard class=""></en-clipboard></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2017, at 8:44 AM, Ioi Lam <<a href="mailto:ioi.lam@oracle.com" class="">ioi.lam@oracle.com</a>> wrote:</div><div class=""><div class=""><br class="">On 6/2/17 6:40 AM, Chris Hegarty wrote:<br class=""><blockquote type="cite" class="">On 02/06/17 00:14, Ioi Lam wrote:<br class=""><blockquote type="cite" class="">...<br class=""><br class="">The gem is hidden in the compile.0.jta file. It contains something like:<br class=""><br class=""> -sourcepath <blahblah>:/jdk/foobar/test/lib:<blahblah><br class=""><br class="">So if my test refers to a class under /test/lib, such as<br class="">jdk.test.lib.process.ProcessTools, javac will be able to locate it under<br class="">/jdk/foobar/test/lib/jdk/test/lib/process/ProcessTools.java, and will<br class="">build it automatically.<br class=""><br class="">So really, there's no reason why the test must explicitly do an @build<br class="">of the library classes that it uses.<br class=""></blockquote><br class="">Sure, you're relying on the implicit compilation of dependencies<br class="">by javac. Look at the output, where it compiles the library<br class="">classes to. It is part of the classes directory for the<br class="">individual test. That means that the library classes will need<br class="">to be compiled many many times. The @build tag will compile<br class="">the library classes to a common output directory, where they<br class="">can be reused ( unless I'm missing something ).<br class=""><br class="">-Chris.<br class=""></blockquote>Yes, @build will compile classes so that they can be reused. But why should it be the responsibility of every test to do this?<br class=""><br class="">To reuse my malloc metaphore -- is it reasonable for every program that uses malloc to explicitly build libc?<br class=""><br class="">By the way, jtreg arranges the output directory of the test by the directory they sit in, so<br class=""><br class=""> jdk/test/foo/bar/XTest.java<br class=""> jdk/test/foo/bar/YTest.java<br class=""><br class="">will all output their .class files to the same directory. Therefore, the amount of duplicated classes is not as bad as you might think. We've been omitting the @build tags in the hotspot tests and we haven't seen any problems.<br class=""><br class="">- Ioi<br class=""></div></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></div></div></div></body></html>