RFR(S): 8049071: Add jtreg jobs to JPRT for Hotspot
Mikael Vidstedt
mikael.vidstedt at oracle.com
Thu Jul 10 20:06:35 UTC 2014
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
>>>>
>
More information about the hotspot-dev
mailing list