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

[Christian Tornqvist]

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