Review request 7157734 testcase corrections (use TESTVMOPTS).

Kevin Walls kevin.walls at oracle.com
Tue Apr 17 00:15:14 PDT 2012


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



More information about the hotspot-runtime-dev mailing list