RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag

Erik Helin erik.helin at oracle.com
Tue Dec 18 04:27:10 PST 2012


Christian,

thanks for reviewing this! See comments inline:

On 12/18/2012 01:16 PM, Christian Törnqvist wrote:
> I agree with Stefan, test/sanity could be such a place. There's already a WBApi test in there. I also think the bugid directory (/8004691) could be omitted since the bug id is already in the test.

The latest webrev (based on the feedback by Stefan), is available here:

http://cr.openjdk.java.net/~ehelin/8004691/webrev.01/

This change moves the test to the hotspot/test/sanity folder and does 
_not_ make use of a folder named after the bugid.

What do you think of this change?

Thanks,
Erik

> Thanks,
> Christian
>
> -----Original Message-----
> From: Stefan Karlsson
> Sent: den 18 december 2012 11:24
> To: Erik Helin
> Cc: hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR (XS): 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag
>
> Looks good.
>
> Though, I'd prefer if the test was not put in the gc directory, since this flag could be used by all HotSpot groups.
>
> thanks,
> StefanK
>
> On 12/18/2012 10:52 AM, Erik Helin wrote:
>> Hi all,
>>
>> this change adds a jtreg test that runs the internal vm tests.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~ehelin/8004691/webrev.00/
>>
>> Summary:
>> There are a couple of tests in HotSpot C++ source code that can be run
>> with the flag -XX:+ExecuteInternalVMTests. These tests are run in JPRT
>> queues, but they are not run as part of the nightly testing.
>>
>> This change adds an empty jtreg test that starts the VM with the flag
>> -XX:+ExecuteInternalVMTests, thereby running the internal VM tests.
>>
>> Since -XX:+ExecuteInternalVMTests only works with a non-product build
>> of the VM, the test also uses the flag
>> -XX:+IgnoreUnrecognizedVMOptions to make sure the test works, but does
>> nothing, when run with a product build of HotSpot.
>>
>> Testing:
>> JPRT
>>
>> Thanks,
>> Erik
>



More information about the hotspot-runtime-dev mailing list