Review request 7157734 testcase corrections (use TESTVMOPTS).

[Kevin Walls]

I checked, and see no other hardcoded -server etc in the open src 
tests.  I updated the webrev in place to take out that -server, I'd be 
happy with that.

If David you or anybody else is concerned about the impact, I'll leave 
it -- but I'd prefer to put this tidying up in place...

Many thanks!
Kevin


On 17/04/12 08:15, 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
>>>
>