All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=833321

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=afc7b59b266f6cf824d443fc12ed09121f4d5a7af7e94aa5975452e6d08eb2dd


Bot(s) for this bug's original alert(s):

chromium-rel-win7-x64-dual

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11e546aac40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/11e546aac40000

[AdTracking] Include the top of the stack in AdTracker detection by jkarlin@chromium.org
https://chromium.googlesource.com/chromium/src/+/bf5b0e09aa81fd00a9586d71cecf96e3e508e946

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Aleksey, does an increase in desktop memory make sense to you from calling SourceLocation::Capture more often?

400 Kb.. Without DevTools SourceLocation::capture should capture only top stack trace frame. We cache symbolized version of this frame and we cleanup this cache under memory pressure.
I assume that per frame this cache should take not more then hundreds bytes. So even if it takes 400 bytes, it means that we cached 1000 additional frames. I am not sure what pages is loaded by this test and is it reasonable amount of frames or we leaked something else.

Thanks Aleksey. The CL in question calls SourceLocation::capture each time a resource is loaded, so we'd get to the thousands very quickly. Is the v8 frame cache bounded in size? 

Closing as wontfix since it's a cache that will free itself under memory pressure.