New issue
Advanced search Search tips

Issue 785007 link

Starred by 5 users

Issue metadata

Status: WontFix
Owner:
Closed: Nov 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

16.7%-24.9% regression in memory.top_10_mobile at 515952:515999

Project Member Reported by tdres...@chromium.org, Nov 14 2017

Issue description

See the link to graphs below.
 
Project Member

Comment 1 by 42576172...@developer.gserviceaccount.com, Nov 14 2017

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

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


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

android-webview-nexus5X
Project Member

Comment 3 by 42576172...@developer.gserviceaccount.com, Nov 15 2017

Cc: mstarzinger@chromium.org
Owner: mstarzinger@chromium.org
Status: Assigned (was: Untriaged)

=== Auto-CCing suspected CL author mstarzinger@chromium.org ===

Hi mstarzinger@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Michael Starzinger
  Commit : 23883b85f21a2c61515cb57064b19901ae666884
  Date   : Thu Nov 09 09:31:15 2017
  Subject: [deoptimizer] Turn deopt entries into immovable Code objects.

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:v8:effective_size_avg/background/after_http_search_yahoo_com_search__ylt_p_google
  Change       : 22.93% | 7480362.66667 -> 9195357.33333

Revision                           Result                  N
chromium@515951                    7480363 +- 707583       6      good
chromium@515951,v8@1ea3fd2e13      6978953 +- 37548.7      6      good
chromium@515951,v8@6aa3349afb      7097540 +- 482225       6      good
chromium@515951,v8@a9c908eb40      7195339 +- 777536       6      good
chromium@515951,v8@23883b85f2      8476392 +- 39307.0      6      bad       <--
chromium@515951,v8@b9c9932202      8484911 +- 37097.8      6      bad
chromium@515951,v8@d1193e3c6c      8478793 +- 72302.3      6      bad
chromium@515951,v8@2328e4d196      8479739 +- 37120.8      6      bad
chromium@515952                    9195348 +- 66084.9      6      bad
chromium@515953                    9196520 +- 62054.2      6      bad
chromium@515954                    9162056 +- 79874.4      6      bad
chromium@515957                    9178560 +- 60435.3      6      bad
chromium@515963                    9164923 +- 78932.6      6      bad
chromium@515975                    9198052 +- 80055.6      6      bad
chromium@515999                    9195357 +- 35928.4      6      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=http.search.yahoo.com.search..ylt.p.google memory.top_10_mobile

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8962913653344387632


For feedback, file a bug with component Speed>Bisection
Project Member

Comment 4 by 42576172...@developer.gserviceaccount.com, Nov 15 2017

 Issue 784960  has been merged into this issue.
Cc: u...@chromium.org
This is expected as it just moves code objects that have previously been untracked into V8's heap and now tracks them as part of large-object space. These are three code objects with a size of 164928 bytes each. The same memory was allocated before, but not accounted for by V8 (or Chrome). The resident sizes reported by the OS remain unchanged everywhere. The difference is not due to increased memory footprint it is only due to changes in reporting. Hence we consider this WontFix.

That being said, there still is something actionable here. Ulan and I dug further, thanks Ulan! Now that we properly track the memory usage for these objects, one can see that there is large discrepancy between the requested size (i.e. 164928 bytes) and the allocated/commited size (i.e. 524288 bytes) due to alignment requirements. This sums up to more than one MB of wastage in practice that we could return to the OS.
Project Member

Comment 6 by 42576172...@developer.gserviceaccount.com, Nov 15 2017

 Issue 784434  has been merged into this issue.
Status: WontFix (was: Assigned)
Marking as WontFix as per comment #5. The remaining work-item mentioned there was added to the GC backlog.
Project Member

Comment 8 by 42576172...@developer.gserviceaccount.com, Nov 21 2017

Cc: mvstanton@google.com mvstan...@chromium.org
 Issue 787420  has been merged into this issue.
Project Member

Comment 9 by 42576172...@developer.gserviceaccount.com, Nov 21 2017

 Issue 787419  has been merged into this issue.
Project Member

Comment 10 by 42576172...@developer.gserviceaccount.com, Nov 21 2017

 Issue 787403  has been merged into this issue.
Project Member

Comment 11 by 42576172...@developer.gserviceaccount.com, Nov 22 2017

 Issue 787397  has been merged into this issue.
Project Member

Comment 12 by 42576172...@developer.gserviceaccount.com, Nov 22 2017

 Issue 787454  has been merged into this issue.

Comment 13 by u...@chromium.org, Nov 23 2017

Cc: jgruber@chromium.org
 Issue 785074  has been merged into this issue.

Sign in to add a comment