The FontCache currently grows without bound, which means we're leaking the CGFontRefs and HFONTs used to construct the FontPlatformData objects held by the cache.
Some quotes from Hyatt on this issue:
<dhyatt> it's not obvious how to change it without hurting perf
<dhyatt> the tentative idea i had was to refcount FontDatas
<dhyatt> and just pretend like FontPlatformData is always a "temporary"
<dhyatt> to avoid massive refcount churn on the fontplatformdata
<dhyatt> if you look at fontdata's destructor
<dhyatt> (i guess simplefontdata now)
<dhyatt> it does actually have code to delete the HFONT and release the cgfontref
<dhyatt> it never gets called
<dhyatt> i just mean i wrote the code assuming that someday the fontdatas would get destroyed
<dhyatt> purged from the cache etc
*** Bug 18263 has been marked as a duplicate of this bug. ***
This doesn't matter much on OS X (I don't think). But on Windows, there are only 65k GDI Object Handles per user session. These handle "leaks" can end up causing Safari to take up an unfair number of handles.
The HFONTs are now owned by the FontPlatformData (not the SimpleFontData). One possible solution would be to have a way to invalidate those and make the SimpleFontData check the validity before any other accees. You'll also need a way to regenerate the FontPlatformData if they were invalidated (you need a FontDescription and a family name for that IIRC).
Fixed in <http://trac.webkit.org/changeset/33056>.
The bug is not fixed in TOT. PlatformFontData objects which hold on to HFONTs and CGFontRefs are still held indefinitely by the FontPlatformDataCache.