RFR(S): JDK-6622468 : TEST_BUG: Time to retire the @debuggeeVMOptions mechanism used in the com.sun.jdi infrastructure

[Daniel D. Daugherty]

Sounds like a wonderful plan.

Dan


On 8/27/13 4:55 AM, Staffan Larsen wrote:
> How about a combination? By default we use -vmoptions/-javaoptions for the debuggee. But if the property jdi.debuggee.VMOptions is specified we will use that instead. This would allow -vmoptions/-javaoptions for simplicity but the property for added control when that is necessary.
>
> /Staffan
>
>
> On 26 aug 2013, at 16:08, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>
>> So if we really want to be able to use different options for the debugger and the debuggee, then a solution would be a separate property that contains the options to send to the debuggee (as proposed in the original bug report). Something like:
>>
>> jtreg .... -javaoption:'-Djdi.debuggee.VMoptions="-server -Xcomp"'
>>
>> and then the debugger would make sure to include this when launching the debuggee. This would still be better than the @debuggeeVMOptions solution. A little tricker to parse in shell based tests, though.
>>
>> /Staffan
>>
>> On 26 aug 2013, at 15:48, Daniel D. Daugherty <daniel.daugherty at oracle.com> wrote:
>>
>>> On 8/26/13 5:27 AM, Staffan Larsen wrote:
>>>> On 26 aug 2013, at 13:03, David Holmes <David.Holmes at 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
>>>>>>