[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-2d-dev
Subject: Re: [OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
From: Jim Graham <james.graham () oracle ! com>
Date: 2013-04-09 17:15:59
Message-ID: 51644CCF.3000603 () oracle ! com
[Download RAW message or body]
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@geo-solutions.it \
> <mailto:andrea.aime@geo-solutions.it>>
> On Sat, Mar 30, 2013 at 2:01 PM, Laurent Bourgès <bourges.laurent@gmail.com \
> <mailto:bourges.laurent@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
>
> -------------------------------------------------------
>
>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic