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

Phil Race philip.race at oracle.com
Thu Mar 28 20:51:30 UTC 2013

B'ccing discuss and core-libs as I realise this is mostly spam for those lists.

On 3/28/2013 1:40 PM, Andrea Aime wrote:

On Thu, Mar 28, 2013 at 8:38 PM, Phil Race <philip.race at oracle.com_ _<mailto:philip.race at oracle.com>> wrote:

Maintaining a pool of objects might be an appropriate thing for an applications, but its a lot trickier for the platform as the application's usage pattern or intent is largely unknown. Weak references or soft references might be of use but weak references usually go away even at the next incremental GC and soft references tend to not go away at all until you run out of heap.

At the same time, the current decision is affecting some applications badly. I've seen the same happening for another old java2d bug, where the alpha tile is cached and coordinated with JVM synchronized statement that kill scalability in server side applications heavily using Java2D (e.g, map servers): http://bugs.sun.com/viewbug.do?bugid=6508591

In fact that bug is not related to pisces, or the issue here. its in the closed source ductus code which is native, not java.

For these kinds of decisions sometimes it's not possible to find a one size that fits all: it would be good if there was some way for the application to plug-in their own behavior, ideally with a Graphics2D rendering hint, less ideally with a system variable (a JVM can run multiple applications, not all might have the same needs). Now, I understand that today (java 7 or java 8) one could plug-in their own rasterizer, yet writing a rasterizer from scratch is kind of a tall order.

The pluggable interface wasn't so that others could do it, it was just so that JDK could operate with either pisces or ductus.

-phil.

Being able to get some control on these kind of decisions via hints would be nicer imho.

Cheers Andrea

More information about the core-libs-dev mailing list