[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    [OpenJDK 2D-Dev] StrikeCache implementation question
From:       linuxhippy () gmail ! com (Clemens Eisserer)
Date:       2009-04-25 14:37:31
Message-ID: 194f62550904250737h5c96ea56mbf891d8e193b56ba () mail ! gmail ! com
[Download RAW message or body]

Hi Phil,

Thanks a lot for your very detailed answers and for the background
information, good to know why things have been done the way there are
:)

> Linux & Solaris VMs have the heuristic that 2GB and 2 CPUs is a server.
> This old rule was controversial even at the time due to its likelihood
> of becoming as dated as "640K is enough for anyone".
Yes I know ... I tried to avoid a rant ;)

> There's a certain amount of flexibility allowed in the spec as to when
> soft references are freed. The server VM's GC policy wants to keep them
> until it otherwise would run out of memory.
Sure, however the problem is that the GC is used to manage resources
which live outside of the heap.
Running TransformAnim resulted only in a 300mb java-heap, however
1,5gb allocated on the "native" side.
I have to admit I don't know any application doing as crazy stuff as
TransformAnim, so this problem maybe non-existent for real software ;)

> I'm not sure if either fine-tuning or wholesale replacement will
> make it easy to manage to the limits of the Xserver whilst being
> friendly to other uses. The java-level code is there to handle
> the software glyph cache, and probably its not going to be easily
> bent to manage the hardware glyph cache to the same limits.
>
> The D3D & OpenGL pipelines push this down into their implementations.
> See src/share/native/sun/font/AccelGlyphCache.c. Maybe its something
> like this you were hoping to replace, but it may have been the best
> policy.
Yes, (old) xrender the pipeline currently has something similar to
AccelGlyphCache, however for XRender I don't have any fixed limit of
glyphs nor any cache-surface handling - thats why I thought I could
throw it away at all.
I have a half-completed pure-java replacement, so I'll just finish it.

> Perhaps using weak references for non-simple transforms.
> Or, if the size of a strikeCache for a Font exceeds some limit,
> flushing some or all of it.
Good idea :)

> Right now it doesn't care. I've not seen this be
> a problem in practice but its many years since I last measured it, and
> I certainly haven't measured its impact on the Xrender pipeline.
I just read the comment, so I've no evidence if that is really a problem at all.

Thanks again, Clemens


[prev in list] [next in list] [prev in thread] [next in thread]