[OpenJDK 2D-Dev] RFR 8144446: Automate the Marlin crash test

[Jim Graham]

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.graham at oracle.com
> <mailto:james.graham at 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...
>