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.gra...@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.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... >> >> -- -- Laurent Bourgès
