On 8/26/13 5:27 AM, Staffan Larsen wrote:
On 26 aug 2013, at 13:03, David Holmes <david.hol...@oracle.com> wrote:
If your test-jdk and compile-jdk are the same then you will have trouble
telling them apart :)
That aside I would have thought it quite reasonable for the debugger and
debuggee VMs to need different options - hence the debuggeeVMOptions.
Do you have an example where this would be necessary?
Yes. When testing slow configurations like fastdebug Server -Xcomp,
you really don't want both the debugger and debuggee VMs running in
that mode. If you execute the test suites that way, you'll get a lot
of timeouts because the debugger will take forever to "drive" the
debuggee.
In my personal test suite setup, I run debugger VMs with product Client
VM -Xmixed and the debuggee VMs with the target config. The only way to
do that is something like @debuggeeVMOptions. As far as I know, JavaTest/
JTREG doesn't directly support the concept of dual-VM tests (debugger/
debuggee or client/server) in so far as having a means of specifying
different options for the two VMs.
Dan
Thanks,
/Staffan
David
On 23/08/2013 9:26 PM, Staffan Larsen wrote:
The JDI tests have some quite arcane way of sending command line options to the
debuggee. Options have to be put into a file called @debuggeeVMOptions before
invoking jtreg. This was apparently implemented before there was a way in jtreg
to set -vmoptions/-javaoptions.
I'd like to remove this crufty code and instead use the value of
-vmoptions/-javaoptions when launching the debuggee. This would make it a lot
simpler and more consistent to launch these tests.
The current test infrastructure puts the same options in @debuggeeVMOptions as
in -javaoptions when launching the JDI tests.
I am not quite sure about the difference between -vmoptions and -javaoptions.
It seems both are used to change the options of the JVM running the test.
Because of this I pick up both values and forward them to the launching of the
debuggee JVM. However, I can't see any other tests that use TESTJAVAOPTS, they
all seem to use TESTVMOPTS. The problem with that for my case is that the test
infrastructure uses -javaoptions instead of -vmoptions.
webrev: http://cr.openjdk.java.net/~sla/6622468/webrev.00/
bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6622468
Thanks,
/Staffan
