RFR(S): 8050407: Add jtreg compiler tests to Hotspot JPRT jobs
vladimir.kozlov at oracle.com
Thu Sep 4 19:33:03 UTC 2014
This looks better.
On 9/4/14 1:42 AM, Albert wrote:
> doesn't it make more sense to select tests based on their 'usefulness'?
I agree. But we need to take into account its running time too.
I assume Zoltan did a quick review of tests on usefulness.
> For example, it seems to me that adding a regression test that was
> based on a fix of a segmentation fault in compiled code makes more sense
> than adding a test that checks the consistency of rarely used command line
Agree. Which tests in the list do flags testing?
We should also exclude unstable tests (have to look on history of the test).
> How about adding tests based on their priorities? Maybe it makes more sense
> to add a test of a corresponding P1 bug than adding a test of a P5 bug?
We can't add P1 test if it takes more then 1 min to run. I would prefer
to run 5 x 10 sec P3 tests instead. We would test more code this way.
Also Bug's priority was not accurate before as it is now.
> On 08/28/2014 08:02 PM, Zoltán Majó wrote:
>> please review the following patch.
>> Bug: Add jtreg compiler tests to Hotspot JPRT jobs
>> Problem: The test/TEST.groups file lists JTREG compiler tests executed
>> in JPRT (target name: 'hotspot_compiler'). We need to determine the
>> list of tests from test/compiler that should be executed in JPRT. The
>> total time of execution should be less than 10 minutes on slowest
>> Solution: The slowest platform in JPRT is currently solaris_sparcv9. I
>> executed all open JTREG tests from test/compiler on solaris_sparcv9
>> and measured the "work time" of each test. Then, tests were sorted in
>> ascending order of their work time. To construct the subset, I first
>> added the test with the lowest work time to the subset and then
>> continued adding tests until a time limit L is reached.
>> Limit L is set to 80% of the original time budget (10 minutes). L is
>> set conservatively to account also for JPRT "cleanup", "init", and
>> "finishing" time, as well as for the variation of tests' "work time".
>> (The profiling measurements contain only "work time".)
>> The subset contains 77 tests. The longest executing test in the subset
>> takes 6.9 seconds.
>> Webrev: http://cr.openjdk.java.net/~zmajo/8050407/webrev.00/
>> Testing: Ran subset on all platforms in both west and stockholm JPRT.
>> Execution times of tests are as follows:
>> linux_i586-fastdebug-c1-hotspot_compiler success(03m 01s)
>> linux_i586-fastdebug-c2-hotspot_compiler success(03m 39s)
>> linux_x64-fastdebug-c2-hotspot_compiler success(03m 32s)
>> macosx_x64-fastdebug-c2-hotspot_compiler success(03m 48s)
>> solaris_sparcv9-fastdebug-c2-hotspot_compiler success(08m 41s)
>> solaris_x64-fastdebug-c2-hotspot_compiler success(03m 00s)
>> windows_i586-fastdebug-c1-hotspot_compiler success(03m 39s)
>> windows_i586-fastdebug-c2-hotspot_compiler success(03m 54s)
>> windows_x64-fastdebug-c2-hotspot_compiler success(04m 51s)
>> linux_i586-fastdebug-c1-hotspot_compiler success(02m 31s)
>> linux_i586-fastdebug-c2-hotspot_compiler success(02m 39s)
>> linux_x64-fastdebug-c2-hotspot_compiler success(02m 53s)
>> macosx_x64-fastdebug-c2-hotspot_compiler success(04m 10s)
>> solaris_sparcv9-fastdebug-c2-hotspot_compiler success(05m 55s)
>> solaris_x64-fastdebug-c2-hotspot_compiler success(03m 06s)
>> windows_i586-fastdebug-c1-hotspot_compiler success(02m 34s)
>> windows_i586-fastdebug-c2-hotspot_compiler success(03m 07s)
>> windows_x64-fastdebug-c2-hotspot_compiler success(04m 33s)
>> We get close to the 10 minute budget (87% usage on West for
>> Thank you and best regards,
More information about the hotspot-compiler-dev