Dear Jim,<br><br>I advocated I only looked at the netbeans memory profiler's output: no more megabytes allocated !<br><br>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.<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Quick questions - which benchmarks were run before/after?  I see a lot of benchmark running in your Pisces improvement thread, but but none here.<br></blockquote><div><br>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.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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).<br></blockquote><div><br>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).<br>
<br>Don't you have at oracle any test platform to perform such tests / benchmark ?<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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...</blockquote>
<div class="h5"><br>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) ?<br>
<br>Maybe verbose:gc output may help ?<br><br>Finally I spent a lot of time on pisces renderer and running MapBench to show performance gains.<br><br>Thanks for your interesting feedback,<br><br>Laurent<br>
<br>
On 4/5/2013 5:20 AM, Laurent Bourgčs wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear java2d members,<br>
<br>
I figured out some troubles in java2d.pipe.AAShapePipe related to both concurrency & memory usage:<br>
- 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()<br>
- 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<br>
<br>
Here are profiling screenshots:<br>
- 4 threads drawing on their own buffered image (MapBench test):<br>
<a href="http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_byte_tile.png" target="_blank">http://jmmc.fr/~bourgesl/<u></u>share/AAShapePipe/AAShapePipe_<u></u>byte_tile.png</a><br>
<br>
- excessive int[] / Rectangle creation:<br>
<a href="http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_int_bbox.png" target="_blank">http://jmmc.fr/~bourgesl/<u></u>share/AAShapePipe/AAShapePipe_<u></u>int_bbox.png</a><br>
<a href="http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_rectangle_bbox.png" target="_blank">http://jmmc.fr/~bourgesl/<u></u>share/AAShapePipe/AAShapePipe_<u></u>rectangle_bbox.png</a><br>
<br>
Here is the proposed patch:<br>
<a href="http://jmmc.fr/~bourgesl/share/AAShapePipe/webrev-1/" target="_blank">http://jmmc.fr/~bourgesl/<u></u>share/AAShapePipe/webrev-1/</a><br>
<br>
I applied a simple solution = use a ThreadLocal or ConcurrentLinkedQueue (see useThreadLocal flag) to cache one AAShapePipeContext per thread (2K max).<br>
As its memory footprint is very small, I recommend using ThreadLocal.<br>
<br>
Is it necessary to use Soft/Weak reference to avoid excessive memory usage for such cache ?<br>
<br>
Is there any class dedicated to such cache (ThreadLocal with cache eviction or ConcurrentLinkedQueue using WeakReference ?) ?<br>
I think it could be very useful at the JDK level to have such feature (ie a generic "GC friendly"cache )<br>
<br>
Regards,<br>
Laurent<br>
</blockquote>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"></div></blockquote></div><br>