Hi Phil, > - 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 > http://kennke.org/~roman/fontwork/webrev/src/share/classes/sun/font/Type1Font.java.sdiff.html 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 temporary files. > - 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 in parallel. /Roman -- 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
