Review request 7157734 testcase corrections (use TESTVMOPTS).

[David Holmes]

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