Correction for the reproduction: activate complex text on Android in Font.cpp.

behdad@, what's the expected lifecycle of the retrieved table hb_blob_t's. Should the last instances of them go away only when the hb_face_t is destroyed? Or is the lifecycle shorter and they should only last for the duration of "callback-to-retrieve-table", "use", "destroy right away"?

If the first is the case, we really need to think about the lifecycle of our FontPlatformData objects. When shaping needs a HarfBuzzFace object, we get the SkTypeface uniqueID() from the typeface() of FontPlatformData, and create a hb_face_t object for those, then add it to the HarfBuzzFontCache.

In most of the situations, i.e. if nothing changes in the system's font configuration during the lifetime of the single process browser, we never delete previously create FontPlatformData objects, and thus never call destructors of HarfBuzzFace, and never remove the hb_face_t objects from the cache.

I've updated the CL to track by table tag, for the above page cycler test, single process, Chromium debug on Linux.

Tag: head leftover kb 0
Tag: hhea leftover kb 0
Tag: GPOS leftover kb 145.408
Tag: vhea leftover kb 0
Tag: OS/2 leftover kb 0
Tag: GSUB leftover kb 28.5391
Tag: vmtx leftover kb 990.488
Tag: hmtx leftover kb 1055.77
Tag: GDEF leftover kb 3.16406
Tag: cmap leftover kb 103.367
---------------------
Total: kb 2326.74

Okay, it looks like when the hb_font_t cached in HbFontCacheEntry is going away, all the blobs are cleaned up. Experimentally I removed the m_harfBuzzFace member from FontPlatformData and created the HarfBuzzFace objects only temporarily. This removes the hb_blob_t leakage but also makes things a lot slower since it disables that caching.

What this boils down to: Our caches for FontPlatformData objects and SimpleFontData do not have any eviction strategy, except: "process killed" - so in a single process environment like the Android web view, they just keep growing and all FontPlatformData objects are kept alive, and in turn they keep the HarfBuzzFace objects and hb_font_t's around - and that's where we create hb_blob_t's that are kept in memory. For page cycler tests in single proecss, this means that they reach a maximum after the first cycle. But then keep getting reused at least.

Other findings: The purge method of the FontDataCache is broken, because the refcounting of the objects returned from the cache is not kept track of correctly.

Correct.  I still think mmap()ing, and some sane eviction policy, is the right way to do.