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

[Laurent Bourgès]

Jim,

My last chance for tonight !

Here is another webrev that disables two long tests (dasher) in CrashTest
but fixes a state cleanup bug in Renderer (doChecks=true):
http://cr.openjdk.java.net/~lbourges/marlin/marlin-8144446.2/

Note: the modified CrashTest detected this bug in Renderer (happening only
with 2Gb off-heap overflow) so I keep both classes together in the same
patch as the fix in Renderer is very small.

The CrashTest seems faster now.

Laurent

2015-12-09 23:31 GMT+01:00 Jim Graham <james.graham at oracle.com>:

> 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...
>>
>>


-- 
-- 
Laurent Bourgès
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20151210/6c0c0a9a/attachment.html>