Same thing is happing to me as well

I have to use... Safari... :(

Sam issue here. Tried all three versions of Chrome, Stable, Beta & dev. All 3 are doing the same thing on new macOS Sierra

Can confirm that Chrome on macOS 10.12 is causing very high CPU and memory utilization. 

Every Chrome process that comes with an extension or a tab uses 600MB to 700MB more than what the Chrome Task Manager reports.

May be related to  Issue 620355 , which is about a high wakeup count.

First pass suggests this is a Sierra bug. A renderer process on about:blank is using 701MB, and the allocation seems to come from within CTFontDescriptorCreateMatchingFontDescriptor()

Attaching the result of running with MallocStackLogging=YES and `malloc_history <renderer_pid> -allBySize`

Report shows 273 (!) allocations for 670MB:

273 calls for 671069488 bytes: thread_7fffe57cc300 | 0x10aa63b34 | main | ChromeMain | 0x10e8b95a6 | 0x10e8ba360 | 0x112dad27f | 0x10e92abad | 0x10e943521 | 0x10e8fdd64 | 0x10e8fe58e | -[NSRunLoop(NSRunLoop) runMode:beforeDate:] | CFRunLoopRunSpecific | __CFRunLoopRun | __CFRunLoopDoSources0 | __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ | 0x10e8fd914 | 0x10e9214ca | 0x10e8fdf0d | 0x10e92bb5b | 0x10e92b7fc | 0x10e92b4ec | 0x10e908c0b | 0x112242779 | 0x1122437c9 | 0x10e908c0b | 0x10f8791e8 | 0x1121e7fa9 | 0x10f88542c | 0x10f8854b0 | 0x112d5843f | 0x112d59c57 | 0x112d59df2 | 0x112d633ae | 0x11078bf89 | 0x111123d11 | 0x11112699b | 0x111113d29 | 0x111113cd3 | 0x11111268a | 0x11111adfa | 0x110d90a1c | 0x110bca523 | 0x110bbadb6 | 0x110bbdc21 | 0x110c43d11 | 0x110c43bf2 | 0x110f540ce | 0x110f54195 | 0x110e71fa5 | 0x110e724a0 | 0x110e72909 | 0x110ef3e44 | 0x110f0844e | 0x110f08060 | 0x110f0afe9 | 0x110f06fba | 0x110f09597 | 0x110f0dc94 | 0x110f0eb42 | 0x110f14cec | 0x110f17995 | 0x1112f9a80 | __NSGetMetaFontInstance | +[__NSFontTypefaceInfo typefaceInfoForPostscriptName:options:] | CTFontDescriptorCreateMatchingFontDescriptor | TDescriptor::CreateMatchingDescriptor(__CFSet const*, double, unsigned long) const | TDescriptor::InitBaseFont(bool) | TDescriptor::CreateMatchingDescriptorInternal(__CFSet const*, bool) const | ContainsAndIsOnlySearchableAttribute(__CFDictionary const*, TDescriptorSource const&, __CFString const*, unsigned long) | TDescriptorSource::CopyFontDescriptorPerPostScriptName(__CFString const*, unsigned long, unsigned long) const | TSplicedFontStash::TSplicedFontStash() | TSplicedFontStashImp::CreateSplicedFonts() | XTCopyFontsWithProperties | TGlobalFontRegistry::TGlobalFontRegistry() | pthread_once | _os_once | __pthread_once_handler | TGlobalFontRegistry::CreateRegistry() | TGlobalFontRegistry::RegisterSystemFontsLocally(bool) | TGlobalFontRegistry::RegisterSystemFontsLocally(TFontRegistryProtocol&, bool) | TLocalFontRegistryImp::RegisterFont(__CFURL const*, __CFDictionary const*, unsigned int, unsigned int, __CFError**) const | CGFontCreateFontsWithURL | CGFontCreateFontsWithPath | create_private_data_with_path | FPFontCreateFontsWithPath | TFont::CreateFontEntitiesForFile(char const*, bool, TSimpleArray<TFont*>&, bool, short, char const*) | TFont::CreateFontEntities(char const*, bool, TSimpleArray<TFont*>&, bool&, short, char const*, bool) | TFileDataSurrogate::TFileDataSurrogate(char const*, bool) | TFileDataReference::TFileDataReference(char const*) | TFileDataReference::MapOrRead(char const*, int) | malloc 

I'll see if I can get some Chrome stacks.

Deleted: all_by_size.txt 6.7 MB

all_by_size.txt 6.7 MB View Download

Triggered in blink::systemNSFont

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutThemeMac.mm?q=systemNSFont&sq=package:chromium&l=206

These are just doing calls to 

[NSFont fooFontOfSize:[...]]

Maybe this should not be getting invoked from within a sandbox.




Stack fragment:

blink::parseUASheet(WTF::String const&)
blink::StyleSheetContents::parseString(WTF::String const&)
blink::StyleSheetContents::parseStringAtPosition(WTF::String const&, WTF::TextPosition const&)
blink::CSSParser::parseSheet(blink::CSSParserContext const&, blink::StyleSheetContents*, WTF::String const&)
blink::CSSParserImpl::parseStyleSheet(WTF::String const&, blink::CSSParserContext const&, blink::StyleSheetContents*)
bool blink::CSSParserImpl::consumeRuleList<blink::CSSParserImpl::parseStyleSheet(WTF::String const&, blink::CSSParserContext const&, blink::StyleSheetContents*)::$_0>(blink::CSSParserTokenRange, blink::CSSParserImpl::RuleListType, blink::CSSParserImpl::parseStyleSheet(WTF::String const&, blink::CSSParserContext const&, blink::StyleSheetContents*)::$_0)
blink::CSSParserImpl::consumeQualifiedRule(blink::CSSParserTokenRange&, blink::CSSParserImpl::AllowedRulesType)
blink::CSSParserImpl::consumeStyleRule(blink::CSSParserTokenRange, blink::CSSParserTokenRange)
blink::CSSParserImpl::consumeDeclarationList(blink::CSSParserTokenRange, blink::StyleRuleBase::RuleType)
blink::CSSParserImpl::consumeDeclaration(blink::CSSParserTokenRange, blink::StyleRuleBase::RuleType)
blink::CSSParserImpl::consumeDeclarationValue(blink::CSSParserTokenRange, blink::CSSPropertyID, bool, blink::StyleRuleBase::RuleType)
blink::CSSPropertyParser::parseValue(blink::CSSPropertyID, bool, blink::CSSParserTokenRange const&, blink::CSSParserContext const&, blink::HeapVector<blink::CSSProperty, 256ul>&, blink::StyleRuleBase::RuleType)
blink::CSSPropertyParser::parseValueStart(blink::CSSPropertyID, bool)
blink::CSSPropertyParser::parseShorthand(blink::CSSPropertyID, bool)
blink::CSSPropertyParser::consumeSystemFont(bool)
blink::LayoutThemeMac::systemFont(blink::CSSValueID, blink::FontStyle&, blink::FontWeight&, float&, WTF::AtomicString&) const
blink::systemNSFont(blink::CSSValueID)
__NSGetMetaFontInstance
+[__NSFontTypefaceInfo typefaceInfoForPostscriptName:options:]
CTFontDescriptorCreateMatchingFontDescriptor

Deleted: 600mb.txt 11.8 KB

600mb.txt 11.8 KB View Download

So.. potential fix in https://codereview.chromium.org/2073693002 . I've verified that it reduces the memory footprint of a renderer showing about:blank by ~600MB. I don't know enough about fonts in blink to assess whether there's a downside at all.

Did you file a rdar? Even if we change this, that seems like something Apple might want to fix for other apps.

Not yet - I'll have a go at minimizing it tomorrow. It's possible there are codepaths other than the one in LayoutThemeMac.mm tripping this too (e.g. for heavier workloads than "about:blank"), but the code in LayoutThemeMac.mm seems kinda wasteful regardless.

Ok - new fix up in https://codereview.chromium.org/2075953002/

In December, WebKit added a new sandbox exception in http://wkrev.com/192805 and it looks like we need the same. It cites <rdar://problem/23508753>, but the public stuff says merely `Update the sandbox profile for Mac WebKit to allow access to the "com.apple.fonts" service.`

There are a few other changes to their sandbox profile -- https://github.com/WebKit/webkit/commits/master/Source/WebKit2/WebProcess/com.apple.WebProcess.sb.in -- maybe one of those will let us rename our processes in Activity Monitor the way Safari does..

"maybe one of those will let us rename our processes in Activity Monitor the way Safari does.."

Our not renaming our processes in Activity Monitor hasn't anything to do with sandbox profiles, but everything to do with being unwilling to make connections to the WindowServer that they are willing to make.

Unless the SPI they use for that has changed in Sierra (which BTW would be awesome if it has) nothing should be different on that front.

This needs to make it to M52. 

Early Stable release is scheduled in 2nd week of July.

Please have the fix ready and merge it to M52 branch once it is baked in Canary by early July accordingly as this bug is marked as Stable Release Blocker. 

 Issue 622471  has been merged into this issue.

Trent can we get this landed and merged?

Greg: Can you look at the new attack surface this week?

Yes I will look into what the new daemon is and what the attack surface is.

** IMPORTANT change in M52 merge date due to first 2 weeks of July no release weeks **
M52 Stable is launching very soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged ASAP. All changes MUST be merged into the release branch by 5pm on July 1 to make into the desktop Stable final build cut. Thank you!

Just to reiterate #23, if we're going to get a fix into M52 the change needs to land by Thursday (so that by Friday, the drop-dead date for cherry-picking to M52, we have at least one Canary build with the patch).

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

commit 56fd33cb2374b335e1c309c2af2940ad469ccee3
Author: tapted <tapted@chromium.org>
Date: Tue Jun 28 20:21:53 2016

Add com.apple.fonts to the sandbox profiles for Sierra

It was done for WebKit in http://wkrev.com/192805

Without it, the renderer process can't talk to the font server on macOS
10.12 Sierra and spawns an entire font server in each renderer process.

This CL reduces the memory footprint of each renderer process by ~600MB
on macOS 10.12 Beta (16A201w).

BUG= 619981 

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

[modify] https://crrev.com/56fd33cb2374b335e1c309c2af2940ad469ccee3/content/ppapi_plugin/ppapi.sb
[modify] https://crrev.com/56fd33cb2374b335e1c309c2af2940ad469ccee3/content/renderer/renderer.sb

We do not have Mac OSX Sierra in house with us to verify the fix on ToT build.

tapted@, is it safe to merge in to M52 branch ?

I can't speak to the safety of merging to M52, but I confirm that renderer memory usage with the latest Canary is no longer in the 900Mb range. 

Yes - should be good to merge. Verified on the 2783.2 Canary - fix is working as intended. Requesting merge of r402523 to m52

Your change meets the bar and is auto-approved for M52 (branch: 2743)

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

commit 5d5932d3b15fb98a6f501262876f817b814db97b
Author: Trent Apted <tapted@chromium.org>
Date: Wed Jun 29 23:52:52 2016

[merge-m52] Add com.apple.fonts to the sandbox profiles for Sierra

It was done for WebKit in http://wkrev.com/192805

Without it, the renderer process can't talk to the font server on macOS
10.12 Sierra and spawns an entire font server in each renderer process.

This CL reduces the memory footprint of each renderer process by ~600MB
on macOS 10.12 Beta (16A201w).

BUG= 619981 

Review-Url: https://codereview.chromium.org/2075953002
Cr-Commit-Position: refs/heads/master@{#402523}
(cherry picked from commit 56fd33cb2374b335e1c309c2af2940ad469ccee3)

Review URL: https://codereview.chromium.org/2104283003 .

Cr-Commit-Position: refs/branch-heads/2743@{#537}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/5d5932d3b15fb98a6f501262876f817b814db97b/content/ppapi_plugin/ppapi.sb
[modify] https://crrev.com/5d5932d3b15fb98a6f501262876f817b814db97b/content/renderer/renderer.sb