[OpenJDK 2D-Dev] Review Reqeust for Bug 100068 - SunGraphics2D exposes a reference to itself while non fully initialised
Mario Torre
mario.torre at aicas.com
Tue Aug 4 20:36:42 UTC 2009
Il 22/07/2009 02:11, Jim Graham ha scritto:
> It's odd that J2DBench showed a difference since nothing you did should
> have affected those benchmarks. I don't think it has any benchmark which
> shows the impact of a pipeline validation, so your standalone test is
> the only one that I think addresses the issue.
>
> Rather than setting up a machine for a 72 hour run (not sure a run of
> what, though - J2DBench?), I'd rather see either trying to do the check
> with a virtual method call (Pipe.needsLoops) or just going back to the
> old style of initializing them in the validation branches that we know
> need them and we can revisit this mechanism some other time when we have
> the time to really figure out how to make it cheap. In particular, I
> have some ideas for how to make validation incredibly cheap at the cost
> of a few K of lookup tables per SurfaceData, but I think the scale of
> that is beyond us for now...
>
> ...jim
Hi Jim,
I tried some more of the j2d benchmark but you're right, looks like no
one of them causes a revalidate, so they are all useless for this
specific case.
I implemented the method based approach. What I did was to introduce an
interface that all loops implements, this interface consist of a single
method that returns a boolean.
I made the implementation final everywhere to try to limit the impact of
it, although I'm not sure this is 100% correct in all cases, but the
impact is still too high. In my opinion we should try to go with the
interface approach, it's really less costly and less complex, basically
no impact at all in all the tests.
I attach two results here. The first run iterates 1000000 times, two
times for warm-up, then one more time to do the actual measurement.
The second run is more "longish" :) each loop is augmented to 100000000.
As I make this test and collect the stats via a script (well, attached,
but it's not the coolest script in the world), I didn't make it smart
enough to tell you what each JDK actually is, so this is the explanation:
OPEN_JDK0 == build 1.7.0-internal-neugens_2009_07_27_18_10-b00
contains the patch in webrew.06 (the one with the methods, linked here)
OPEN_JDK1 == build 1.7.0-internal-neugens_2009_07_15_15_31-b00
is a pure JDK build
OPEN_JDK2 == build 1.7.0-internal-neugens_2009_07_15_14_30-b00
is the "old" webrew.05 patch (marker interface).
Finally, the webrew:
http://cr.openjdk.java.net/~neugens/100068/webrev.06/
Please, ignore the ".hgignore" changes in the patch.
Cheers,
Mario
--
Mario Torre, Software Developer, http://www.jroller.com/neugens/
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-44
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF
USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Geschäftsführer: Dr. James J. Hunt
Please, support open standards:
http://endsoftpatents.org/
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: whole_run_01.txt
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/whole_run_01.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: whole_run_02.txt
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/whole_run_02.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Main.java
Type: text/x-java
Size: 1987 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/Main.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run_tests.sh
Type: application/x-shellscript
Size: 1564 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20090804/2fc445f8/run_tests.sh>
More information about the 2d-dev
mailing list