[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
bourges.laurent at gmail.com
Wed Apr 3 09:01:22 UTC 2013
Thanks for your valueable feedback!
Here is the current status of my patch alpha version:
>> There is still a lot to be done: clean-up, stats, pisces class instance
>> recycling (renderer, stroker ...) and of course sizing correctly initial
>> arrays (dirty or clean) in the RendererContext (thread local storage).
>> For performance reasons, I am using now RendererContext members first
>> (cache for rowAARLE for example) before using ArrayCaches (dynamic arrays).
> Thank you Laurent, those are some nice speedups.
I think it can still be improved: I hope to make it as fast as ductus or
maybe more (I have several idea for aggressive optimizations) but the main
improvement consist in reusing memory (like C / C++ does) to avoid wasted
memory / GC overhead in concurrent environment.
> About the thread local storage, that is a sensible choice for highly
> concurrent systems, at the same time, web containers normally complain about
> orphaned thread locals created by an application and not cleaned up.
> Not sure if ones created at the core libs level get special treatment, but
> in general, I guess it would be nice to have some way to clean them up.
You're right that's why my patch is not ready !
I chose ThreadLocal for simplicity and clarity but I see several issues:
1/ Web container: ThreadLocal must be clean up when stopping an application
to avoid memory leaks (application becomes unloadable due to classloader
2/ ThreadLocal access is the fastest way to get the RendererContext as it
does not require any lock (unsynchronized); As I get the RendererContext
once per rendering request, I think the ThreadLocal can be replaced by a
thread-safe ConcurrentLinkedQueue<RendererContext> but it may become a
3/ Using a ConcurrentLinkedQueue<RendererContext> requires an efficient /
proper cache eviction to free memory (Weak or Soft references ?) or using
statistics (last usage timestamp, usage counts)
Any other idea (core-libs) to have an efficient thread context in a web
I'm not familiar with the API, but is there any way to clean them up when
> the graphics2d gets disposed of?
The RenderingEngine is instanciated by the JVM once and I do not see in the
RenderingEngine interface any way to perform callbacks for warmup / cleanup
... nor access to the Graphics RenderingHints (other RFE for tuning
> A web application has no guarantee to see the same thread ever again
> during his life, so thread locals have to be cleaned right away.
I advocate ThreadLocal can lead to wasted memory as only few concurrent
threads can really use their RendererContext instance while others can
simply answer web requests => let's use a
ConcurrentLinkedQueue<RendererContext> with a proper cache eviction.
> Either that, or see if there is any way to store the array caches in a
> global structure backed by a concurrent collection to reduce/eliminate
Yes, it is a interesting alternative to benchmark.
More information about the core-libs-dev