[OpenJDK 2D-Dev] StrikeCache implementation question

[Phil Race]

Clemens Eisserer wrote:
> Hi,
> 
> Today I tried replacing my own glyph-cache logic with StrikeCache's,
> simply removing a glyph from the native cache when StrikeCache removes
> it.
> For XRender thats more or less all logic I need :)
> That didn't work out very well. I get the server-compiler by default,

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

> which doesn't seem to release SoftReferences even when forcing GCs.

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.

> So after ~50.000 cached glyphs my Xserver died :-/
> Even when using the X11 pipeline which doesn't do any native caching,
> running Java2Demo's TransformAnim with 10 animated strings results in
> java consuming 1.8Gb RSS after some minutes.

We've basically let GC handle this, but I can imagine some kind of
limit maybe worthwhile if it can be lightweight and fits into the
existing model. 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.

> Would a cache-algoyrthm instead of using References cause troubles
> with StrikeCache's multithreading capability, or would the performance
> impact be too high?

If you mean wholly replace the Java-level logic, I think that's a bit much.
1.4 and earlier had a cache algorithm and 1.5 replaced that with the
current scheme where as much as possible (not just the cache) is
multi-threaded. Single threaded work was resultingly faster and MT
went from negative scaling to almost linear. Its also been tuned
and proven over a couple of releases so I'd be reluctant to touch that.
And letting the glyph cache grow beyond hard-coded limits made for
really significant performance improvements for CJK text.

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.

> It would also solve the problem with References cleared immediatly
> when starting applications with the client-jvm.

I think only the client VM would do that, but there's already mitigation.
We keep strong references to the most recent strikes, so this shouldn't
happen much. If I were to make any change here it would be to make the
code that adds a strike to that strongly referenced list make sure
they are unique. 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.

-phil.
> 
> Thank you in advance, Clemens