Hi Laurent,
Quick questions - which benchmarks were run before/after? I see a lot of
benchmark running in your Pisces improvement thread, but but none here.
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).
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...
...jim
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
- excessive int[] / Rectangle creation:
http://jmmc.fr/~bourgesl/share/AAShapePipe/AAShapePipe_int_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/
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
