Hi Laurent,
That sounds good. I'm all for fast tests! ;)
We might want to fix them in separate bugs, though. If the new mods to
the test case lead to failures, then we should integrate them after we
fix the underlying problems, though, to prevent testing failures that
might block an integration...
...jim
On 12/9/15 2:25 PM, Laurent Bourgès wrote:
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
<mailto: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...
