RFR (S) CR 8023638: Add the regression test for 8006997

[Staffan Larsen]

Could we have a helper for this in ProcessTools? In case you forget what the property is called again.

/Staffan

On 27 aug 2013, at 14:29, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:

> No, we should not update ProcessTools with this, many of the tests that use
> ProcessTools need explicit control over the command line. The ones that
> should pass on javaopts should add the test.java.opts themselves to the
> arguments passed to the child process.
> 
> / Christian
> 
> -----Original Message-----
> From: hotspot-runtime-dev-bounces at openjdk.java.net
> [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Leonid
> Mesnik
> Sent: Tuesday, August 27, 2013 2:06 PM
> To: David Holmes
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (S) CR 8023638: Add the regression test for 8006997
> 
> We should update ProcessTools so it add
> 'System.getProperty("test.java.opts")'  to test java options.
> 
> Also some of combinations are invalid and test should silently pass
> (skip) in such case.
> For example tests on CMS should just pass when we test any other GC and
> specify this as -javaoption.
> 
> 
> Leonid
> 
> On 08/27/2013 07:50 AM, David Holmes wrote:
>> On 26/08/2013 11:41 PM, Daniel D. Daugherty wrote:
>>> So when we're trying to test with -Xcomp we actually don't?
>>> That sounds rather wrong to me.
>> 
>> This is a general problem we are facing with tests that launch other 
>> VMs. The initial test gets invoked with a bunch of flags from the 
>> current "test configuration" but these don't get passed through to the 
>> launched VM. There is a bug open for this:
>> 
>> 8019502 The tests which launch Java from code should be modified to 
>> launch Java with options used to run the testing Java
>> 
>> but it isn't a black and white situation. Sometimes, like with your 
>> debuggeeVMoptions, you don't want the same flags.
>> 
>> Of course when we do want it we need a mechanism to allow it. The 
>> shell scripts could access env variables set by jtreg. I think Java 
>> code can access system properties with the same info. This then needs 
>> to be passed through to the Processtools.
>> 
>> Just as an aside: note also that jtreg doesn't know when 
>> -javaoptions/-vmoptions is passing a VM selection flag (-client, 
>> -server, -minimal) or mode flag (Xcomp, Xint, Xmixed) and so the 
>> version info in the jtr file is often wrong.
>> 
>> Cheers,
>> David
>> 
>>> Dan
>>> 
>>> 
>>> On 8/26/13 7:38 AM, Leonid Mesnik wrote:
>>>> Dan
>>>> 
>>>> ProcessTools.createJavaProcessBuilder don't use test java options. 
>>>> So all java invocations are always in '-Xmixed'.
>>>> 
>>>> Leonid
>>>> 
>>>> On 08/26/2013 05:12 PM, Aleksey Shipilev wrote:
>>>>> Hi Dan,
>>>>> 
>>>>> On 08/24/2013 12:14 AM, Daniel D. Daugherty wrote:
>>>>>> On 8/23/13 5:24 AM, Aleksey Shipilev wrote:
>>>>>>> Here's the webrev:
>>>>>>>    http://cr.openjdk.java.net/~shade/8023638/webrev.00/
>>>>>> hotspot/test/runtime/contended/Options.java
>>>>>>     I count 11 Java process invocations. Will the default timeout
>>>>>>     of 120 seconds be enough for a fastdebug '-server -Xcomp'
>>>>>>     run on something like Solaris SPARC.
>>>>> Linux i5/x86_64 laptop passes this test in 5 seconds. I think there 
>>>>> is enough headroom for slower machines.
>>>>> 
>>>>>>     The fragments:
>>>>>> 
>>>>>>         "must be the between"
>>>>>>         "must be the multiple of 8"
>>>>>> 
>>>>>>     probably match the real error messages, but those messages
>>>>>>     aren't quite proper English. I expected:
>>>>>> 
>>>>>>         "must be in between"
>>>>>>         "must be a multiple of 8"
>>>>> Yes. Unfortunately, this is what VM outputs. Does it make sense to 
>>>>> fix the error messages in VM along with the regression test? If so, 
>>>>> here is the new webrev:
>>>>>   http://cr.openjdk.java.net/~shade/8023638/webrev.01/
>>>>> 
>>>>> -Aleksey.
>>>> 
>>>> 
>>> 
> 
> 
> --
> Leonid Mesnik
> JVM SQE
> 
>