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

Andrea Aime andrea.aime at geo-solutions.it
Fri Mar 29 14:01:59 UTC 2013

On Thu, Mar 28, 2013 at 9:49 PM, Phil Race <philip.race at oracle.com> wrote:

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

I was not contesting that bug here, just making a parallel on method:
to write one size fits all code did not work there, where only the desktop
were taken into account, nor here, where it seems particular applications
being affected by design decisions in array resizing.

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

That's a bummer, I was hoping to be able to do something about the poor
in which all java based web map servers are into,
maybe trying to write a different rasterizer, because pisces is too slow
and sometimes
generate low quality output, and ductus does not scale up.

What is the suggested approach to address that? Trying to patch pisces
What if some performance decisions need to favour server side usage in
order to get
the desired results?


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more

Ing. Andrea Aime
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20130329/a5a0810b/attachment.html>

More information about the 2d-dev mailing list