I was able to reproduce the results.

From the Blink side it looks FontCustomPlatformData is destructed earlier. But it looks like the decoded font data inside SkTypeface is somehow still alive.

I need to look at how SkTypeface is retained. Does anyone know about this?

drott@: Do you have any insights on this?

From what I read in the code, it looked like FontFaceCache holds references to the type faces in one of the font fact lists.

IIUC we also need to purge skia's font cache in addition to FontCache. RenderThreadImpl::ClearMemory() does the job but we only call it under memory pressure.

I would not say I have insights exactly, but I am aware that our font handle lifecycles need improvement. I have a TODO item towards this end, and by that I mean mainly managing FontPlatformData and SimpleFontData objects better. 

The other bigger issue we have is that we do not have a good way to count whether we still need a font, e.g. if it's still DOM connected, or whether we can dispose of it. At this point, I think it's mainly Blink's responsibility to manage SkTypeface lifecycles right, before we dig for further savings below the SkTypeface API.

Too early font cache purging of course is not the solution either, since decompression of a web font, parsing and glyph rasterization are costly operations.

So... what will be a next step action for this?

 Issue 418929  is an enabling initial step, then we need to work on keeping a count of active font handles from the DOM or render tree.

I agree that it's Blink's responsibility to clear the SkTypeFace objects it keeps in cache. Can we have a simple solution there with limit on the size of the total size of FontFaceCache and evicting items based on an LRU list? do you think lru would be a good way to tell if we still need a font face?

LRU may work, the problem is one step before: For LRU we need reliable information on how often a font is in-use or touched and when it is ageing and a candidate for cache eviction, and we need to ensure that the desctruction of a FontPlatformData object actually destroys the SkTypeface. 

At this point SimpleFontData and FontPlatformData (which owns the SkTypeface) have cyclic ownership ties and I think this needs to be cleaned up first before we can apply a LRU strategy on these objects.