Chrome Version: Cr-Commit-Position: refs/heads/master@{#385388} (51.0.2702.0)
OS: Linux

URL (if applicable) where the memory bloat occurred: https://www.w3.org/2010/09/web-on-tv/slides/1009-tv-web-chaals/demos/webfonts.htm 

Can you reproduce this memory bloat?
Yes

What steps will reproduce this memory bloat (or if it's not reproducible,
what were you doing until then)?
(1) Run content_shell with the following command: out/Default/content_shell --process-per-tab --enable-heap-profiling --trace-startup="disabled-by-default-memory-infra" --trace-startup-duration=60 --no-sandbox
(2)Input URL https://www.w3.org/2010/09/web-on-tv/slides/1009-tv-web-chaals/demos/webfonts.htm and load
(3) Input URL about:blank and load
(4) Repeat steps 2 and 3 several times during the trace duration
(5) Load the generated chrometrace.log in chrome://tracing (I've been using chrome beta)
(6) Observe skia memory usage on the renderer process: the sk_glyph_cache keep growing with sets of 2 glyphs

Expected result:
The web font stored in the glyph cache should either be removed between loads, or should be re-used instead of being re-added.

Additional information:
* This issue also reproduces using --single-process
* I have trouble seeing if this "leak" happens with every load of the web fonts page or not. Since I'm testing it manually I don't know how many loads I fit into the trace. But on a 120 sec trace I get 4 copies of the web fonts, which seems a bit low compared to the amount of loads I should have fit in during that time. Possibly, the glyphs are not "leaked" every time? Hard to say!
* I have chrometrace logs that I can share, but they are really big (even compressed) so I will do that on request.