Jim,
Thanks for explaining me the different jtreg modes (newbie) !
I tried disabling few long tests (using dashes) that are less critical (no
failure expected, just insane rendering work):
test(0.1f, false, 0);
test(0.1f, true, 7f);
Doing so, I detected a new issue in the Renderer.dispose() when the
addLine() fails due to the AIOB (2GB off-heap overflow):
the range buckets_minY/maxY are not properly set, normally by
endRendering(), and the edgeBucket arrays are not properly zero-filled !
I will work on this issue ASAP and propose a fix within the same bug.
Maybe we should defer this fix as I agree it can be made faster ~ 12s now
vs 52s before on my laptop.
Laurent
2015-12-09 22:31 GMT+01:00 Jim Graham <james.gra...@oracle.com>:
> Hi Laurent,
>
> One clarification - there are levels of automation.
>
> On 12/9/15 6:35 AM, Laurent Bourgès wrote:
>
>> Agreed it is possible but then the bug JDK-8144446
>> <https://bugs.openjdk.java.net/browse/JDK-8144446> becomes invalid.
>>
>
> Prior to this fix, jtreg wouldn't even see the test since it did not have
> any tags in it at all. Adding tags of "some sort" makes it able to be run
> by the test mechanism, which I call "automated". Right now, nobody who
> runs jtreg will run this test no matter what command line arguments they
> use with the tool.
>
> Once jtreg recognizes a test there are variations that let it decide
> when/if to run it. It has 3 main modes (related to the /manual tag):
>
> no options - all tests are run, both manual and automatic
> -a - ignore all /manual tests
> -m - run only /manual tests
>
> -a primarily means "there is no human here to provide interaction", but a
> few non-manual tests take a long time.
>
> On the other hand, I just did a test run of all tests (with -a) in
> sun/java2d and the total time was so long that the 30 seconds wasn't that
> noticeable. On the other hand, there were a lot of tests run so the long
> time was less because a lot of tests take a long time than it was about the
> fact that a lot of conditions were tested in that time. For the record, the
> next longest test in that part of the repo takes 8 seconds, so this new
> test is almost 5 times longer than any existing java2d test. Only the
> longest 4 tests took more than 5 seconds.
>
> I did find a test with "@ignore slow test" in another part of the repo and
> I ran it and it took 8 seconds as well, so somebody out there considers 8
> seconds to be too long to run under ordinary circumstances.
>
> I tend to want to push hard on making tests be faster and leaner. I see
> so many bug fixes come in with automated tests that only have to run a
> single method and see if it returns the right answer and yet somehow the
> test needs to launch a Frame and wait for it to open and then do a screen
> readback - when a simple render to a BufferedImage would take 1/100th the
> time.
>
> I'll withdraw my suggestion to make this one /manual, but it would be nice
> if it could do its work in just a few seconds instead...
