Issue metadata
Sign in to add a comment
|
16.7%-24.9% regression in memory.top_10_mobile at 515952:515999 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Nov 14 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8962913653344387632
,
Nov 15 2017
=== 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
,
Nov 15 2017
Issue 784960 has been merged into this issue.
,
Nov 15 2017
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.
,
Nov 15 2017
Issue 784434 has been merged into this issue.
,
Nov 21 2017
Marking as WontFix as per comment #5. The remaining work-item mentioned there was added to the GC backlog.
,
Nov 21 2017
,
Nov 21 2017
Issue 787419 has been merged into this issue.
,
Nov 21 2017
Issue 787403 has been merged into this issue.
,
Nov 22 2017
Issue 787397 has been merged into this issue.
,
Nov 22 2017
Issue 787454 has been merged into this issue.
,
Nov 23 2017
|
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Nov 14 2017