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

[Igor Veresov]

Looks fine..

igor

On Jul 10, 2014, at 1:06 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:

> 
> Anybody? Pleeeease?
> 
> Cheers,
> Mikael
> 
> On 2014-07-07 16:12, Mikael Vidstedt wrote:
>> 
>> 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
>>>>> 
>> 
>