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, Laurent 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 >
