[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
Jim Graham
james.graham at oracle.com
Tue Apr 9 17:15:59 UTC 2013
Hi Laurent,
I haven't looked at the changes in depth yet, but I wanted to echo my comments on the AAShapePipe thread - make sure you do benchmark testing on multiple platforms and double check if caching small objets actually helps anything (otherwise it is unnecessary code complexity and possibly a detrimental change given that Hotspot optimizes small object allocation so much)...
...jim
On 4/1/2013 2:20 PM, Laurent Bourgès wrote:
> Andra & Jim,
>
> Here is the current status of my patch alpha version:
> http://jmmc.fr/~bourgesl/share/java2d-pisces/
>
> There is still a lot to be done: clean-up, stats, pisces class instance recycling (renderer, stroker ...) and of course sizing correctly initial arrays (dirty or clean) in the RendererContext (thread local storage).
> For performance reasons, I am using now RendererContext members first (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays).
>
> I provided the patch as zip file and few benchmark using Andrea's MapBench (Xmx128m):
> - OpenJDK 8 PATCHED:
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 3687 ms
> 2 threads and 20 loops per thread, time: 3693 ms
> 4 threads and 20 loops per thread, time: 6849 ms
>
> Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> 1 threads and 20 loops per thread, time: 27266 ms
> 2 threads and 20 loops per thread, time: 33628 ms
> 4 threads and 20 loops per thread, time: 61577 ms
>
> - OpenJDK 8 REFERENCE:
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 3982 ms
> 2 threads and 20 loops per thread, time: 4852 ms
> 4 threads and 20 loops per thread, time: 8842 ms
>
> Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> 1 threads and 20 loops per thread, time: 55889 ms
> 2 threads and 20 loops per thread, time: 77691 ms
> 4 threads and 20 loops per thread, time: 141981 ms
>
> - Oracle JDK8 DUCTUS:
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 1894 ms
> 2 threads and 20 loops per thread, time: 3905 ms
> 4 threads and 20 loops per thread, time: 7485 ms
>
> Loading drawing commands from file: /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> Loaded DrawingCommands: DrawingCommands{width=1400, height=800, commands=135213}
> Testing file /home/bourgesl/libs/openjdk/mapbench/dc_shp_alllayers_2013-00-30-07-00-47.ser
> 1 threads and 20 loops per thread, time: 20911 ms
> 2 threads and 20 loops per thread, time: 39297 ms
> 4 threads and 20 loops per thread, time: 103392 ms
>
> As you can see, patched openJdk8 performs better and it is very noticeable on big drawings (dc_shp_alllayers_2013-00-30-07-00-47.ser) and better than ductus with 2 threads !!
>
> Laurent
>
>
> 2013/3/30 Andrea Aime <andrea.aime at geo-solutions.it <mailto:andrea.aime at geo-solutions.it>>
>
> On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>
> - clipping issues (dasher, stroker) and spatial resolution (no cpu/memory waste)
>
>
> I see, yes. Indeed in the GeoServer code we already work around some of those issues by
> clipping the geometries read from the database to the graphics2d viewport before giving them
> to the renderer, we had to do that both for performance issues and to avoid OOM errors
> when basic stroke with dasharray is used against a line that is many times longer than the
> current display area
>
> I don't have anything ready, the existing code loads data from spatial database, sets up styles from XML descriptions, turns each spatial db geomety in java shapes
> and so on. But I guess I could concoct something close enough.
> I'm writing some code to gather statistics about the shapes that are actually painted (scrolling over the path iterators) and then I'll try to make a randomized
> shape painter that gets close to those stats.
>
>
> Great news ! I am waiting your test code to perform few benchmarks.
>
> I am using J2DBench but it does not perform such complex drawing (complex shapes ...) or multi threading tests (parallel drawings on buffered images)
>
>
> Ok, I've created a "MapBench" by serializing shapes, strokes and fills from a real GeoServer instance to disk, and have them
> play in a simple multithreaded test harness.
> What you get in the output is not exactly the maps generated by GeoServer since we use a number of tricks to speed up rendering,
> including painting over multiple drawing surfaces (the serializer only handles one), also, some maps have text showing up because
> in order to pain "labels along a line" we actually turn the chars into shapes and place them along the line, but those labels that we
> can predict are "straight" are painted with drawGlyphVector so they won't show up (haven't built a serialization for that case).
>
> Regardless, the test should be good enough to test both performance and scalability.
> Here is the package: http://demo.geo-solutions.it/share/mapbench.zip
>
> It contains:
> * ShapeDumpingGraphics2D, a Graphics2D wrapper writing on disk all draw(Shape) and
> fill(Shape) commands issued to it
> * A bunch of *.ser files, that are the serialized drawing command sequences
> * A bunch of *.png files, which are the rendered versions of the .ser files (for reference)
> * MapDisplay, which reads all *.ser files from a directory and displays them in JFrame and
> generates the .png files as well
> * MapBench, which reads all *.ser files from a directory and repeatedly paints them in a loop
> with a growing number of threads
> * Two txt files with the timings of the benchmarks on my machine for Oracle JDK 7 and
> OpenJDK 7, here is an example comparison:
>
> OpenJDK7:
> Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 3340 ms
> 2 threads and 20 loops per thread, time: 3688 ms
> 4 threads and 20 loops per thread, time: 4665 ms
> 8 threads and 20 loops per thread, time: 7343 ms
>
> Oracle JDK 7:
> Warm up took 29516 ms
> Testing file /tmp/dc_boulder_2013-13-30-06-13-17.ser
> 1 threads and 20 loops per thread, time: 1754 ms
> 2 threads and 20 loops per thread, time: 2878 ms
> 4 threads and 20 loops per thread, time: 6792 ms
> 8 threads and 20 loops per thread, time: 14275 ms
>
> As you can see ductus is significantly faster than pisces, but it has serious scalability
> issues, while pisces scales up a lot better.
>
> The code has been put together in a haste, sorry for the lack of comments, hopefully it is
> simple enough that it's usable anyways.
>
> Cheers
> Andrea
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
>
More information about the 2d-dev
mailing list