Hi Igor, > >> Quick tests are: run Font2DTest on system that has some really large > >> ttf/ttc files. > >> > >> Write simple test that iterates through all available fonts and draw > >> one > >> or all glyphs to bufferedimage. > >> > > > > I wrote a simple test program that gets an array of all fonts and gets > > the baseline for all 0-0xffff characters. (Drawing stuff to BI didn't > > work due to NPE, see stacktrace below. BTW, this makes everything, e.g. > > SwingSet2, kindof unstable, is this a known bug?) > > > > 10 runs of this program with my patch take: 4338ms > > 10 runs of this program w/o my patch take: 4492ms > > > > Can you check process size stats at the end of program? > Guess you can simply exec "ps | grep" and print out result
Ok, it took me a while to figure out a way to measure process size of a program that only runs for a second or so. I am using top -b -d0.1 |grep java to measure memory consumption. Without my patch, the output looks like: 637m 5936 2912 S 37 0.3 0:00.04 java 644m 11m 5408 S 90 0.6 0:00.14 java 645m 12m 5900 S 96 0.6 0:00.24 java 645m 12m 5900 S 95 0.6 0:00.34 java 648m 15m 6224 S 135 0.8 0:00.48 java 648m 17m 6380 S 163 0.9 0:00.65 java 648m 20m 6716 S 145 1.0 0:00.80 java 650m 22m 6908 S 146 1.1 0:00.95 java 650m 24m 7016 S 106 1.2 0:01.06 java 653m 26m 7304 S 152 1.3 0:01.22 java 653m 26m 7324 S 125 1.3 0:01.35 java 654m 26m 7340 S 86 1.3 0:01.44 java 654m 26m 7340 S 0 1.3 0:01.44 java 654m 26m 7340 S 0 1.3 0:01.44 java The first 3 fields here are of interest: virtual memory, resident memory, and shared memory. Typical output of the same program with my patch: 637m 6288 3008 S 37 0.3 0:00.04 java 645m 10m 4676 S 90 0.5 0:00.14 java 645m 10m 4680 S 114 0.5 0:00.26 java 645m 10m 4680 S 95 0.5 0:00.36 java 647m 15m 6224 S 129 0.8 0:00.50 java 648m 17m 6384 S 176 0.9 0:00.69 java 648m 20m 6816 S 111 1.0 0:00.81 java 720m 24m 8620 S 162 1.2 0:00.98 java 894m 26m 10m S 144 1.3 0:01.13 java 806m 26m 9748 S 125 1.3 0:01.26 java 806m 26m 9756 S 115 1.3 0:01.38 java 807m 26m 9760 S 19 1.3 0:01.40 java 807m 26m 9760 S 0 1.3 0:01.40 java 807m 26m 9760 S 0 1.3 0:01.40 java It appears that the programs virtual memory usage grows a little more than w/o my patch :-( However, the actual resident memory stays more or less the same (compared to the version w/o the patch). Also interesting is the short spike in shared memory usage (maybe a font that is already mmapped by the desktop?). This can be explained: when mapping a file into memory, it 'uses' virtual memory of the size of the file, but doesn't actually consume any resident memory as long as the memory is not accessed. So the VM consumtion is growing, but the RM stays the same. Don't know if that is a concern. > > One interesting note here: Everytime this program is run, it shows a > > different number of fonts (around 285-302 fonts). On an OpenJDK6 system > > it constantly shows 360 fonts. > > > This is weird. > I suggest to print out font names and find what is different. Perhaps we > do have bug somethere in 7. > -Dsun.java2d.debugfonts=true may also provide some details on files > being opened. I'll have a look at this later. Cheers, 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
