RFR(S): 8049071: Add jtreg jobs to JPRT for Hotspot

Mikael Vidstedt mikael.vidstedt at oracle.com
Mon Jul 7 23:12:10 UTC 2014


Fixed the comment, removed the loop (the loop logic is btw taken 
directly from jdk/test/Makefile, but I'll follow up on a fix for that 
separately).

Anybody else want to have a look?

top: 
http://cr.openjdk.java.net/~mikael/webrevs/8049071/webrev.01/top/webrev/
hotspot: 
http://cr.openjdk.java.net/~mikael/webrevs/8049071/webrev.01/hotspot/webrev/

Thanks,
Mikael

On 2014-07-03 22:29, David Holmes wrote:
> On 4/07/2014 2:46 PM, David Holmes wrote:
>> Hi Mikael,
>>
>> Generally looks okay - took me a minute to remember that jtreg groups
>> combine as set unions :)
>>
>> A couple of things:
>>
>> 226 # Unless explicitly defined below, hotspot_<x> is interpreted as the
>> jtreg test group <x>
>>
>> The jtreg group is actually called hotspot_<x>
>>
>>   227 hotspot_%:
>>   228         $(ECHO) "Running tests: $@"
>>   229         for each in $@; do \
>>   230                 $(MAKE) -j 1 TEST_SELECTION=":$$each"
>> UNIQUE_DIR=$$each jtreg_tests; \
>>   231         done
>>
>> While hotspot_% can match multiple targets each target will be distinct
>> - ie $@ will only every have a single value and the for loop will only
>> execute once - and hence is unnecessary. This seems borne out with a
>> simple test:
>>
>>  > cat Makefile
>> hotspot_%:
>>          @echo "Running tests: $@"
>>          @for each in $@; do \
>>            echo $$each ;\
>>          done
>>
>>  > make hotspot_a hotspot_b
>> Running tests: hotspot_a
>> hotspot_a
>> Running tests: hotspot_b
>> hotspot_b
>
> Though if you have a quoting issue with the invocation:
>
>  > make "hotspot_a hotspot_b"
> Running tests: hotspot_a hotspot_b
> hotspot_a
> hotspot_b
>
> things turn out different.
>
> David
>
>
>> Cheers,
>> David
>>
>> On 3/07/2014 11:08 AM, Mikael Vidstedt wrote:
>>>
>>> Please review this enhancement which adds the scaffolding needed to run
>>> the hotspot jtreg tests in JPRT.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8049071
>>> Webrev (/):
>>> http://cr.openjdk.java.net/~mikael/webrevs/8049071/webrev.00/top/webrev/ 
>>>
>>> Webrev (hotspot/):
>>> http://cr.openjdk.java.net/~mikael/webrevs/8049071/webrev.00/hotspot/webrev/ 
>>>
>>>
>>>
>>>
>>> Summary:
>>>
>>> We want to run the hotspot regression tests on every hotspot push. This
>>> change enables this and adds four new test groups to the set of tests
>>> being run on hotspot pushes. The new test sets still need to be
>>> populated.
>>>
>>> Narrative:
>>>
>>> The majority of the changes are in the hotspot/test/Makefile. The
>>> changes are almost entirely stolen from jdk/test/Makefile but have been
>>> massaged to support (at least) three different use cases, two of which
>>> were supported earlier:
>>>
>>> 1. Running the non-jtreg tests (servertest, clienttest and
>>> internalvmtests), also supporting the use of the "hotspot_" for when 
>>> the
>>> tests are invoked from the JDK top level
>>> 2. Running jtreg tests by selecting test to run using the TESTDIRS
>>> variable
>>> 3. Running jtreg tests by selecting the test group to run (NEW)
>>>
>>> The third/new use case is implemented by making any target named
>>> hotspot_% *except* the ones listed in 1. lead to the corresponding 
>>> jtreg
>>> test group in TEST.groups being run. For example, running "make
>>> hotspot_gc" leads to all the tests in the hotspot_gc test group in
>>> TEST.groups to be run and so on.
>>>
>>> I also removed the packtest targets, because as far as I can tell
>>> they're not used anyway.
>>>
>>> Note that the new component test groups in TEST.group -
>>> hotspot_compiler, hotspot_gc, hotspot_runtime and 
>>> hotspot_serviceability
>>> - are currently empty, or more precisely they only run a single test
>>> each. The intention is that these should be populated by the respective
>>> teams to include stable and relatively fast tests. Tests added to the
>>> groups will be run on hotspot push jobs, and therefore will be blocking
>>> pushes in case they fail.
>>>
>>> Cheers,
>>> Mikael
>>>



More information about the hotspot-dev mailing list