RFR(XL/M) : 8178788: wrap JCStress test suite as jtreg tests
Stuart Monteith
stuart.monteith at linaro.org
Thu Sep 14 10:26:53 UTC 2017
Thank you Magnus, that's useful.
My working command line is:
make run-test TEST="hotspot_all"
JTREG="VM_OPTIONS=-Djdk.test.lib.artifacts.jcstress-tests-all=$HOME/jcstress.jar"
but it takes an excessively long time to run. Are there plans for a means
to cleanly disable the JCStress JTreg tests so we can efficiently run them
with the JCStress harness?
Thanks,
Stuart
On 14 September 2017 at 08:40, Magnus Ihse Bursie <
magnus.ihse.bursie at oracle.com> wrote:
> Stuart,
>
> On 2017-09-13 20:36, Stuart Monteith wrote:
>
> For the record, if I put my build of jcstress.jar in $HOME, the following
> allows the jcstress tests to run:
>
> make test TEST="hotspot_all" EXTRA_JTREG_OPTIONS="-Djdk.
> test.lib.artifacts.jcstress-tests-all=$HOME/jcstress.jar"
>
> From "make help" and the makefiles themselves, I had expected the follow
> to work:
> make TEST="hotspot_all" JTREG="VM_OPTIONS=-Djdk.test.
> lib.artifacts.jcstress-tests-all=$HOME/jcstress.jar" test
>
> but it does not - the JTREG parameter is apparently ignored. This is
> unfortunate as there is a warning as it is a non-control variable.
>
>
> You are using the "test" target, but the JTREG option is only available
> for the new "run-test" target. Using "test" will invoke the old testing
> framework, which is about to be replaced by a more modern and integrated
> one. In the long term, "test" will invoke the new framework, but during a
> transition period, "run-test" needs to be used.
>
> For what it's worth, I tried your command line (but without the patch
> applied) and verified using LOG=cmdlines that the -D option was indeed
> passed to jtreg.
>
> /Magnus
>
>
>
> Am I wrong in thinking that this was written for testing internall within
> Oracle? I can not find an instance of "com.oracle.jib.api.JibServiceFactory"
> in the OpenJDK project or elsewhere.
>
> BR,
> Stuart
>
> On 8 September 2017 at 16:53, Stuart Monteith <stuart.monteith at linaro.org>
> wrote:
>
>> Hello,
>> I've spent some time on this, and I have to admit that I'm stumped. I
>> get exactly the same errors on x86 on jdk10/hs and jdk10/jdk10 with arecent
>> build of JTReg and JT_HOME set appropriately.
>>
>> Are there any pointers on how this is supposed to be run?
>>
>> Thanks,
>> Stuart
>>
>> On 25 April 2017 at 11:47, Aleksey Shipilev <shade at redhat.com> wrote:
>>
>>> On 04/19/2017 12:12 AM, Igor Ignatyev wrote:
>>> > http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/index.html
>>> >> 69903 lines changed: 69903 ins; 0 del; 0 mod;
>>> > (69524 lines are generated)
>>> >
>>> > Hi all,
>>> >
>>> > could you please review this patch which adds a jtreg test wrapper for
>>> > jcstress test suite and jtreg tests which run jsctress tests thru this
>>> > wrapper?
>>> >
>>> > webrev: http://cr.openjdk.java.net/~iignatyev//8178788/webrev.00/ind
>>> ex.html
>>> > JBS: https://bugs.openjdk.java.net/browse/JDK-8178788 testing:
>>>
>>> TL;DR: This patch introduces more problems than it solves. Just run the
>>> jcstress
>>> tests-all JAR against the tested runtime.
>>>
>>> Wrapping jcstress tests with jtreg defies the purpose of jcstress
>>> harness --
>>> that is, running lots of tests as fast as it possibly could without
>>> affecting
>>> testing quality. For example, by cleverly reusing VMs between the tests,
>>> using
>>> Whitebox to deoptimize without restarting the VMs, etc. It really wastes
>>> CPU
>>> time to run each test in isolation.
>>>
>>> Also, it does not "automatically" work, which defies "easy to run" goal:
>>>
>>> Caused by: java.io.FileNotFoundException: Couldn't automatically resolve
>>> dependency for jcstress-tests-all , revision 0.3
>>> Please specify the location using jdk.test.lib.artifacts.jcstres
>>> s-tests-all
>>> at
>>> jdk.test.lib.artifacts.DefaultArtifactManager.resolve(Defaul
>>> tArtifactManager.java:37)
>>> at jdk.test.lib.artifacts.ArtifactResolver.resolve(ArtifactReso
>>> lver.java:54)
>>> at applications.jcstress.JcstressRunner.pathToArtifact(Jcstress
>>> Runner.java:53)
>>> ... 8 more
>>>
>>> Okay, brilliant! How do I configure this, if I run "make test"?
>>>
>>> CONF=linux-x86_64-normal-server-release LOG=info make test
>>> TEST="hotspot_all"
>>>
>>>
>>> -Aleksey
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170914/70cd6a8a/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list