RFR (S) 8014905: Some hotspot tests should be updated to divide test jdk and compile jdk
David Holmes
david.holmes at oracle.com
Thu May 23 19:21:08 PDT 2013
Hi Christian,
On 24/05/2013 6:22 AM, Christian Tornqvist wrote:
> Hi everyone,
>
> Could I please have some reviews for this small test (library) fix. The
> following tests:
>
> gc\TestG1ZeroPGCTJcmdThreadPrint.java
>
> gc\TestVerifyDuringStartup.java
This test will need modifying as it expects getJDKTool("java") to return
the JVM being tested.
Everything else is running jcmd but I'm not clear if they simply use
jcmd as a mechanism in the test or whether they actually expect to be
testing jcmd from the VM under test?
Overall I'm not at all sure that your change is the best thing to do.
The utilities need to support both compile.jdk and test.jdk, but it
isn't clear to me that your selected defaults are right. For example you
changed ProcessTools.createJavaProcessBuilder to always use the
test.jdk, which is probably normally what is wanted, but sometimes you
might want the compile.jdk. Conversely you didn't change
./testlibrary/com/oracle/java/testlibrary/JDKToolLauncher.java
so it always launches from the compile.jdk when some tests might want to
use it for the test.jdk.
I think we need to support both forms in all the utilities. And I think
all the tests would ideally be specific about which they want to use -
but that is a lot of changes. But defaults need to be consistent
otherwise people will just be confused.
Thanks,
David
-----
> runtime\NMT\BaselineWithParameter.java
> runtime\NMT\JcmdScale.java
> runtime\NMT\JcmdWithNMTDisabled.java
>
> runtime\NMT\MallocTestType.java
>
> runtime\NMT\ShutdownTwice.java
>
> runtime\NMT\SummaryAfterShutdown.java
>
> runtime\NMT\SummarySanityCheck.java
>
> runtime\NMT\ThreadedMallocTestType.java
>
> runtime\NMT\ThreadedVirtualAllocTestType.java
>
> runtime\NMT\VirtualAllocTestType.java
>
> runtime\RedefineObject\TestRedefineObject.java
>
> use the JDKToolFinder.getJDKTool() method to get the path to different
> tools in JDK\bin. This only works if the Java used in the test is a full
> JDK build. If the Java used for testing is a JRE build the JDK tools
> will be available as compile.jdk instead of test.jdk.
>
> The solution was to simply change the getJDKTool() method to use the
> “compile.jdk” property to get the path to the tools (this will be set by
> jtreg to the same value as test.jdk if ‘-compilejdk’ is not specified on
> the command line). I’ve also added getTestJDKTool() and
> getCompileJDKTool() methods so that the tools can be explicitly grabbed
> from either location if necessary.
>
> Webrev can be found at:
> http://cr.openjdk.java.net/~ctornqvi/webrev/8014905/webrev.00/
>
> Bug (not yet visible at time of posting):
> http://bugs.sun.com/view_bug.do?bug_id=8014905
>
> Testing done was to run the above mentioned tests with jtreg using a JRE
> and –compilejdk pointing to a JDK and then again without –compilejdk but
> using a JDK to test.
>
> Thanks,
> Christian
>
More information about the hotspot-runtime-dev
mailing list