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

[Jim Graham]

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

			...jim