[9] RFR(L): 8062854: move compiler jtreg test to corresponding subfolders and use those in TEST.groups

[Zoltán Majó]

Hi David,


thank you for the feedback!

On 11/13/2014 02:57 PM, David Chase wrote:
> On 2014-11-13, at 8:32 AM, Zoltán Majó <zoltan.majo at oracle.com> wrote:
>> The problem with this approach is that if we want to execute a new (short-running) JTREG test in JPRT, the TEST.groups file must be updated to execute the newly added JTREG test. Moreover, the current selection of tests is based on a per-group time limit of 10 minutes (i.e., each test group executes 10 minutes on the slowest JPRT platform available), but it seems that a 15-minute limit is also tolerable.
>>
>> Solution: Move all test directories of the form hotspot/test/<numeric_bug_id> to "functionality-based" directories.  Each functionality-based directory contains tests related to a specific functionality of the VM, for example: hotspot/test/compiler/c1, hotspot/test/compiler/c2, and hotspot/test/compiler/codecache. In the TEST.groups file we list only functionality-based directories, and not individual tests. We also exclude long-running tests.
>> After changes (group / #tests / execution time on solaris_sparcv9 cpus=6 parallelcount=6 cpufreqmhz=2848):
>>
>> hotspot_compiler_1 / 107 / 16m55s
>> hotspot_compiler_2 / 76 / 14m49s
>> hotspot_compiler_3 / 59 / 13m44s
> (Not a Reviewer)
>
> If 15 minutes is a hard limit, I note that 16m 55s is larger than that, and 14m49s is pretty darn close.

The limit is not that "hard", I think. And by accident, the numbers I 
reported before include initialization and cleanup times as well, and 
these are not easily controllable.

Here is only the "work" time for the same runs as before:

hotspot_compiler_1 / work=15m6s
hotspot_compiler_2 / work=13m55s
hotspot_compiler_3 / work=12m43s

> Don’t we run a risk of test-time creep as new tests are added and by-default are run?

Yes, we do, but I think the limit is not that hard, and we can 
re-evaluate test times periodically (when the number of tests 
significantly changes or when we recycle some of our slowest machines).

> But those two issues are small compared to the goodness of this test re-org.
> I think I can live with time-creep risk, though we might need to kick a few tests out of the first group.

I'll look into that.

Thanks and best regards,


Zoltan