On 13/05/2016 20:04, Martin Buchholz wrote:
I tried updating jsr166 to jdk-9+118 today, but there's a snag - jtreg
won't start.
A simple repro is:
jtreg -agentvm -testjdk:/home/martin/jdk/jdk-9-ea+118 .
Agent[0].stdout: Bad value for -Xpatch, no module name specified
Agent[0].stderr: Error: Could not create the Java Virtual Machine.
Agent[0].stderr: Error: A fatal exception has occurred. Program will exit.
It looks like jtreg is synthesizing an -Xpatch flag, but the syntax of
that has changed.
strace shows the flag
"-Xpatch:/home/martin/jsr166/Xpatch/src/test/jtreg/JTwork/patches"
Jonathan has been making -Xpatch related changes to jtreg in mercurial
that may have already fixed it, but if so, making a 4.2-b03 release is
urgent. It would be nice if there were one jtreg binary that could
work with any jdk9 build, but that's understandably difficult.
Of course, jsr166 wants to add its own -Xpatch flags; hopefully that
will be able to peacefully coexist with whatever jtreg ends up doing.
We transitioned to the new form of -Xpatch in jdk-9+118.
jtreg 4.2 b02 can use the old or new form. It's configured via the
useNewXpatch property in the test suite configuration. In jdk-9+118 then
each test root had its TEST.ROOT changed to include useNewXpatch=true so
that jtreg uses the new form of -Xpatch.
For jtreg 4.2 b03 then Jon has removed support for the old form of
-Xpatch. I don't think you need that just yet.
So is this test suit a jsr166 test suite? If so then useNewXpatch=true
or jtreg tip should be okay.
I'll need to defer to Jon on peacefully co-existing as you are both
patching java.base. You can only specify -Xpatch:java.base= only but the
value can specify multiple locations. I suspect -othervm should be fine,
-agentvm mode is where jtreg needs to inject.
-Alan.
