[OpenJDK 2D-Dev] sun.java2D.pisces big memory usage (waste ?)
philip.race at oracle.com
Thu Mar 28 20:49:17 UTC 2013
B'ccing discuss and core-libs as I realise this is mostly spam for those
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
> 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
> 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):
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
JDK could operate with either pisces or ductus.
> Being able to get some control on these kind of decisions via hints
> would be nicer imho.
More information about the core-libs-dev