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

[Phil Race]

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/view_bug.do?bug_id=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