Review request 7157734 testcase corrections (use TESTVMOPTS).

[Kevin Walls]

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