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

Staffan Larsen staffan.larsen at oracle.com
Mon Aug 26 06:15:41 PDT 2013


On 26 aug 2013, at 14:08, David Holmes <David.Holmes at oracle.com> wrote:

> On 26/08/2013 9:27 PM, Staffan Larsen wrote:
>> 
>> On 26 aug 2013, at 13:03, David Holmes <David.Holmes at oracle.com> wrote:
>> 
>>> Staffan,
>>> 
>>> javaoptions will only be passed to the java invocation of the VM under test.
>>> 
>>> vmptions will be passed to all VM invocations including javac from the compile-jdk.
>> 
>> Thanks, that was what I thought. So if my VM under test wants to launch a new VM is would have to use javaoptions + vmoptions.
> 
> I would not expect so. Assuming compile-jdk and test-jdk are different I would expect your launched VM to perhaps, but not necessarily, want javaoptions only.

But vmoptions will also be sent to the VM under test, right? So regardless of compile-jdk and test-jdk being the same or not, the VM under test will be sent both vmoptions and javaoptions.

> There is no clear cut answer as sometimes the options coming in from the testsuite are not compatible with the options you need for the VM you are launching.
> 
>>> 
>>> 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?
> 
> Not off hand. I do recall past bugs/test-issues where the wrong options were being passed though.

As far as I can tell, the current test infrastructure always sets @debuggeeVMOptions to the same thing as javaoptions. This results in both the debugger and the debuggee using the same options (exception, of course, when I try to reproduce a test failure and don't know about @debuggeeVMOptions in which case the debuggee is missing some options and I can't reproduce - which is what I am trying to solve by making this simpler.)

/Staffan



> 
> David
> 
>> 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
>>>> 
>> 



More information about the serviceability-dev mailing list