New issue
Advanced search Search tips

Issue 672213 link

Starred by 1 user

Issue metadata

Status: Duplicate
Owner: ----
Closed: Dec 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug-Regression



Sign in to add a comment

7.9% regression in jetstream at 436594:436744

Project Member Reported by tdres...@chromium.org, Dec 7 2016

Issue description

See the link to graphs below.
 
All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=672213

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgl9-vrQoM


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

chromium-rel-win7-gpu-intel
Mergedinto: 671994
Status: Duplicate (was: Untriaged)

===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : [heap] Ensure finalization of incremental marking even if all allocations
Author  : ulan
Commit description:
  come from the runtime.

This patch fixes an issue of heap growing to max capacity when incremental
marking is finished but cannot finalize due to GC stack guard not triggering.

It can happen if all allocations come from the runtime, for example,
from JSON parser or compiler.

Now before expanding the heap we check if we are above the allocation limit
and the incremental marking needs to be finalized. If so we do not expand
the heap and force GC, which will finalize the incremental marking.
The check is performed for paged spaces and large-object space.

BUG=chromium:670675

Review-Url: https://codereview.chromium.org/2552613004
Cr-Commit-Position: refs/heads/master@{#41524}
Commit  : fdc0aa0c97952e56686157b1023a8085885357b4
Date    : Tue Dec 06 14:06:40 2016


===== TESTED REVISIONS =====
Revision                       Mean     Std Dev  N   Good?
chromium@436593                195.933  2.98887  15  good
chromium@436669                196.067  3.30656  15  good
chromium@436707                196.533  3.11983  15  good
chromium@436726                196.733  3.59629  15  good
chromium@436735                196.2    2.09762  15  good
chromium@436736                196.133  3.96653  15  good
chromium@436736,v8@2da865d8a4  195.333  5.22813  15  good
chromium@436736,v8@ca74343a70  196.733  5.91044  15  good
chromium@436736,v8@fdc0aa0c97  186.667  6.58281  15  bad    <--
chromium@436736,v8@9c9c8d7bb5  185.733  8.6564   15  bad
chromium@436737                186.267  7.4117   15  bad
chromium@436738                185.4    6.60303  15  bad
chromium@436740                185.133  3.11983  15  bad
chromium@436744                185.4    6.89928  15  bad

Bisect job ran on: winx64intel_perf_bisect
Bug ID: 672213

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests jetstream
Test Metric: Score/Score
Relative Change: 5.38%

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/winx64intel_perf_bisect/builds/1245
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8993903431878902656


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=6175832844795904

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Sign in to add a comment