[OpenJDK 2D-Dev] Thoughts about font implementation
roman.kennke at aicas.com
Fri Sep 19 08:04:15 UTC 2008
> - I think its probably peformance neutral - at least as can be
> detected in the SE JDK.
Yeah, that's what I found too. If anything, it becomes very little
faster, but that can also be normal jitter during testing.
> - It probably does increase perceived footprint although
> results will probably vary by platform and
> we'd need to see if people will accept that. I did what
> I hope is a reasonably fair comparison of the two approaches,
> reading all font files on my XP system takes mem usage up to 160Mb
> with the new approach, vs 37Mb with the existing approach.
That is virtual memory or actual resident memory? Sure - virtual memory
mapped into the process increases significantly, as all the font files
appear to be loaded completely into the process. Actual used resident
memory should not increase (at least, did not for my tests under linux).
But I see that the problem is that people use flawed memory usage
analysis tools and will probably scream if the VM uses twice as much
memory than before.
> - There are some cases that need additional work here
> * T2K also, like any rasteriser will need to randomly access the file,
> so has similar code.
Unfortunately I have no control over that code.
> * The new init() methods don't seem to use all their args.
> In particular the T1 font doesn't do anything with the buffer it just read
Oops right. I didn't finish up the Type1 stuff it seems. I can do that
if we come to the conclusion that we actually want this code in OpenJDK.
> * Want to make sure that this works well for the Font.createFont() cases.
> The the only way the BB resources can be freed is via GC. So we have no timely
> way to release these resources,
> And on windows, you can't "delete" a file that's mmapped, so you need
> to be able to know when GC has allowed NIO to free its map with windows
> before you can delete the file, otherwise we'd leave temp files on disk,
> which is something we've tried had to clean up.
Hmm, Font.createFont(InputStream) is a strange beast. I don't like the
idea to copy the stream into a temporary file to begin with. But you are
right, we need to take care of this. For the situation on Windows we
could probably do something with PhantomReference and ReferenceQueue. An
alternative would be to not copy the stream but instead read it into a
ByteBuffer, but this means we'd have to keep all the font data of the
stream in memory. I'd prefer the latter solution because on the systems
I work on I can't guarantee that I have tmp space on the disk at all,
but I suppose for JDK SE it probably makes more sense to copy into
> - Not thought about this much, but even if the above doesn't work out for
> all the SE cases, there's probably no fundamental obstacle to providing
> a DBB path which can be optionally used.
That would be very cool. I'd have to think about how we could have both
Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org
aicas Allerton Interworks Computer Automated Systems GmbH
Haid-und-Neu-Straße 18 * D-76131 Karlsruhe * Germany
http://www.aicas.com * Tel: +49-721-663 968-48
USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe
Geschäftsführer: Dr. James J. Hunt
More information about the 2d-dev