[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?) (original) (raw)

Laurent Bourgès 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:

http://jmmc.fr/~bourgesl/share/java2d-pisces/

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 leaks) 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 but it may become a performance bootleneck 3/ Using a ConcurrentLinkedQueue 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 container ?

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 purposes)

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 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 contention.

Yes, it is a interesting alternative to benchmark.

Regards, Laurent

More information about the core-libs-dev mailing list