Review request 7157734 testcase corrections (use TESTVMOPTS).

[Vladimir Kozlov]

Looks good. Thank you for this clean up.

Vladimir

Kevin Walls wrote:
> 
> Thanks for your time David, yes we may test some tests under a new 
> configuration here - that's a good thing, as the casual observer might 
> think we've been testing such things forever...  At least the number of 
> tests changed is small.
> 
> Cheers
> Kevin
> 
> 
> On 17/04/12 08:54, David Holmes wrote:
>> Hi Kevin,
>>
>> My main concern is simply to flag that these tests might start to fail 
>> for different reasons now. I don't know how/if these get run in 
>> nightly/weekly/promotion testing, but we (you! :) ) need to keep an 
>> eye on them and for all the various configs. For example it may be 
>> that some of these tests will now run for the first time using G1 GC. 
>> JPRT only does "normal" runs.
>>
>> Cheers,
>> David
>>
>> On 17/04/2012 5:15 PM, Kevin Walls wrote:
>>> Thanks David -
>>>
>>> Leaving -server in that example was being conservative, should really
>>> have taken it out, so we rely TESTVMOPTS to tell us if we want to test a
>>> server or client (or whatever) VM. (A test could script could skip
>>> itself if TESTVMOPTS contains values not relevant to the test...).
>>>
>>> TESTVMOPTS is set by jtreg to include things you have asked the test
>>> harness to pass to the JVM, so really not great if the testing
>>> framework/jprt says "doing client tests" and a script is running
>>> -server. TESTVMOPTS usually has client/server and/or -d64, but could
>>> contain whatever you asked jtreg to set, so whatever it contains is what
>>> we want to have tested...
>>>
>>> Any consequences will be exposing things we have not been testing before
>>> (though no major surprises in jprt runs so far...).
>>>
>>> Would any consequences be worse than never testing these tests in 64-bit
>>> mode, as nobody ever puts the file in the test user's home directory,
>>> which means that BIT_FLAG is always blank? 8-)
>>>
>>> I will scan again for other examples of hardcoded -server and suggest a
>>> patch with them all removed. I realise that I'm only addressing your
>>> concern by saying we shouldn't be concerned. 8-)
>>>
>>> Thanks
>>> Kevin
>>>
>>>
>>> On 17/04/12 04:04, David Holmes wrote:
>>>> Hi Kevin,
>>>>
>>>> Not a full review - sorry.
>>>>
>>>> I'm concerned that changes like this:
>>>>
>>>> ! ${TESTJAVA}${FS}bin${FS}java ${BIT_FLAG} -server IsInstanceTest >
>>>> test.out 2>&1
>>>>
>>>> ! ${TESTJAVA}${FS}bin${FS}java ${TESTVMOPTS} -server IsInstanceTest >
>>>> test.out 2>&1
>>>>
>>>> may have unintended consequences as TESTVMOPTS might contain a lot
>>>> more than just -d32 or -d64. That seems to apply to all the changes.
>>>>
>>>> David
>>>>
>>>> On 16/04/2012 7:50 PM, Kevin Walls wrote:
>>>>> Hi -
>>>>>
>>>>> Minor update on this, and am seeking review to push it.
>>>>>
>>>>> I had confirmation from a few people that use of a file in the home
>>>>> directory to trigger 64-bit tests is not in use. Would be great to get
>>>>> rid of these slightly embarrasing tests that just don't test what they
>>>>> claim, and worse still they are used as a model for future tests!
>>>>>
>>>>> http://cr.openjdk.java.net/~kevinw/7157734/webrev.02/
>>>>>
>>>>> Thanks
>>>>> Kevin
>>>>>
>>>>>
>>>>> On 30/03/12 15:30, Kevin Walls wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Various hotpsot .sh testcase scripts do not use the env var
>>>>>> TESTVMOPTS, which is passed by jtreg. They therefore don't set -d64
>>>>>> when we want to test a 64-bit JVM and on Solaris at least this means
>>>>>> we don't test what we think we're testing. We actually run a 32-bit
>>>>>> JVM, and likely not even the one we just built to test.
>>>>>>
>>>>>> What some testcases do do, is to read $HOME/JDK64BIT if it exists, 
>>>>>> and
>>>>>> use the file contents as command-line arguments, or even just as a
>>>>>> flag to know that we should set -d64 when we run java. It seems best
>>>>>> to get rid of this practice. I have asked around and found nobody who
>>>>>> can say that technique is still in use.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~kevinw/7157734.1/webrev/
>>>>>>
>>>>>> Thanks
>>>>>> Kevin
>>>>>
>>>
>