[OpenJDK 2D-Dev] AAShapePipe concurrency & memory waste
james.graham at oracle.com
Tue Apr 9 17:14:23 UTC 2013
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 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...
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):
> - excessive int / Rectangle creation:
> Here is the proposed patch:
> 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 )
More information about the core-libs-dev