[OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste

Laurent Bourgès bourges.laurent at gmail.com
Tue Apr 9 17:34:48 UTC 2013

Dear Jim,

I advocated I only looked at the netbeans memory profiler's output: no more
megabytes allocated !

The main question is: how to know how GC / hotspot deals with such small
allocations ? Is there any JVM flag to enable to see real allocations as
does jmap -histo.

> Quick questions - which benchmarks were run before/after?  I see a lot of
> benchmark running in your Pisces improvement thread, but but none here.

Agreed; I can try running j2dBench on this fix only. I generally run
Andrea's MapBench as I appeared more complex and using multiple threads.

> Also, this should be tested on multiple platforms, preferably Linux,
> Windows and Mac to see how it is affected by differences in the platform
> runtimes and threading (hopefully minimal).

It appears more difficult for me: I can use at work a mac 10.8 and I can
run Windows XP within virtual box (but it is not very representative).

Don't you have at oracle any test platform to perform such tests /
benchmark ?

> Finally, Hotspot is supposed to deal very well for small thread-local
> allocations like the int[4] and Rectangle2D that you optimized.  Was it
> necessary to cache those at all?  I'm sure the statistics for the
> allocations show up in a memory profile, but that doesn't mean it is
> costing us anything - ideally such small allocations are as fast as free
> and having to deal with caching them in a context will actually lose
> performance.  It may be that the tile caching saved enough that it might
> have masked unnecessary or detrimental changes for the smaller objects...

I repeat my question: how can I know at runtime how hotspot optimizes
AAShapePipe code (allocations ...) ? Does hotspot can do stack allocation ?
is it explained somewhere (allocation size threshold) ?

Maybe verbose:gc output may help ?

Finally I spent a lot of time on pisces renderer and running MapBench to
show performance gains.

Thanks for your interesting feedback,


On 4/5/2013 5:20 AM, Laurent Bourgčs wrote:

> Dear java2d members,
> I figured out some troubles in java2d.pipe.AAShapePipe related to both
> concurrency & memory usage:
> - concurrency issue related to static theTile field: only 1 tile is cached
> so a new byte[] is created for other threads at each call to renderTile()
> - excessive memory usage (byte[] for tile, int[] and rectangle): at each
> call to renderPath / renderTiles, several small objects are created (never
> cached) that leads to hundreds megabytes that GC must deal with
> Here are profiling screenshots:
> - 4 threads drawing on their own buffered image (MapBench test):
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**byte_tile.png<http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_byte_tile.png>
> - excessive int[] / Rectangle creation:
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**int_bbox.png<http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_int_bbox.png>
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/AAShapePipe_**
> rectangle_bbox.png<http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_rectangle_bbox.png>
> Here is the proposed patch:
> http://jmmc.fr/~bourgesl/**share/AAShapePipe/webrev-1/<http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-1/>
> I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue
> (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K
> max).
> As its memory footprint is very small, I recommend using ThreadLocal.
> Is it necessary to use Soft/Weak reference to avoid excessive memory usage
> for such cache ?
> Is there any class dedicated to such cache (ThreadLocal with cache
> eviction or ConcurrentLinkedQueue using WeakReference ?) ?
> I think it could be very useful at the JDK level to have such feature (ie
> a generic "GC friendly"cache )
> Regards,
> Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20130409/a1817f6f/attachment.html>

More information about the 2d-dev mailing list