The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/414107a81fdf7231eebc30c45aa14a437561bbbd

commit 414107a81fdf7231eebc30c45aa14a437561bbbd
Author: drott <drott@chromium.org>
Date: Mon Jun 06 18:47:06 2016

Use a FontPlatformData pointer for FontDataCache's key

FontDataCache's key data type was a full FontPlatformData object, not a
pointer to one The value type of that cache is a SimpleFontData object,
which in itself stores a FontPlatformData object type.

If we want to manage memory related to font blobs (OpenType tables, web
font file buffers) we need to come to a situation where the lifecycle of
FontPlatformData objects is absolutely clear.

Previously, adding to the FontDataCache meant one copy of
FontPlatformData for the cache key, and one for the value as an owned
member of SimpleFontData.

In this situation, it is much harder to keep track of where we keep
FontPlatformData objects.

FontPlatformData objects keep a RefPtr<HarfBuzzFace>, which in turn
keeps hb_font objects, which keep references to OpenType tables copied
from Skia. If we cannot destroy FontPlatformData objects after use, we
cannot free the corresponding copied OpenType tables - so over the
lifetime of the renderer we're leaking OpenType table data for stale
FontPlatformData objects.

This is a first step towards fixing this situation and gaining better
control over the lifecylce of FontPlatformData objects.

BUG= 617568 
R=eae,tzik,bashi

Review-Url: https://codereview.chromium.org/2031363002
Cr-Commit-Position: refs/heads/master@{#398079}

[modify] https://crrev.com/414107a81fdf7231eebc30c45aa14a437561bbbd/third_party/WebKit/Source/platform/fonts/FontDataCache.cpp
[modify] https://crrev.com/414107a81fdf7231eebc30c45aa14a437561bbbd/third_party/WebKit/Source/platform/fonts/FontDataCache.h
[modify] https://crrev.com/414107a81fdf7231eebc30c45aa14a437561bbbd/third_party/WebKit/Source/platform/fonts/linux/FontCacheLinux.cpp

> OpenType tables copied from Skia.

(Just an idea)

behdad@: How likely does harfbuzz modify OpenType tables? I wonder if we could avoid copying OpenType tables from Skia.

Even if harfbuzz doesn't modify tables much there are some issues:
- no public api to get OpenType tables from Skia without copy
- lifetime management of references to tables

> - no public api to get OpenType tables from Skia without copy

Yes, this is https://bugs.chromium.org/p/skia/issues/detail?id=5387

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/af675a084051af4b0fd90a66ddbc1373e3ddae8d

commit af675a084051af4b0fd90a66ddbc1373e3ddae8d
Author: jb <jb@opera.com>
Date: Thu Oct 13 10:06:56 2016

Make HarfBuzzFace release SimpleFontData.

HarfBuzzFace did a retained look up of SimpleFontData from the
FontDataCache but never released the SimpleFontData. This caused the
SimpleFontData to remain in the cache, indefinitely holding on to
SkFontFaces and all associated data. This fix makes HarfBuzzFace
release the SimpleFontData when deleted.

BUG= 617568 

Review-Url: https://codereview.chromium.org/2411643002
Cr-Commit-Position: refs/heads/master@{#424993}

[modify] https://crrev.com/af675a084051af4b0fd90a66ddbc1373e3ddae8d/third_party/WebKit/Source/platform/fonts/shaping/HarfBuzzFace.cpp

tzik@, is there a way to analyze the memory impact of this previous change my jb? You mentioned you had a strategy to use the chrome performance dashboard for this purpose? If you have some time, could you perhaps take a look if this change affected memory consumption?