New issue
Advanced search Search tips

Issue 638225 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Large regression with "Stage bytecode preservation" on Octane DeltaBlue

Project Member Reported by rmcilroy@chromium.org, Aug 16 2016

Issue description

Looks like the bytecode preservation staging CL regressed MandreelLatency by a significant amount. Graphs here:

https://chromeperf.appspot.com/report?sid=f04f617f990171423ee848a64c039a84908ee360d72b2cbd952eb925d443feab

Could you please take a look Michi.
 
Summary: Large regression with "Stage bytecode preservation" on Octane DeltaBlue (was: Large regression with "Stage bytecode preservation" on Octane MandreelLatency)
Actually it is DeltaBlue, not MandreelLatency - the dashboard had incorrectly labeled the graphs on the unified graph. Updated graph:

https://chromeperf.appspot.com/report?sid=d838945fe2c5421ed9cc1cfc5ee9c31dfbc14502e10f1a2b378114a5b5ddc1b6
I can somewhat flakily reproduce this locally. The "DeltaBlue" regresses from a stable score to bi-modal behavior. It seems unrelated to the change in the runtime profile, as I can reproduce by just toggling the --ignition-preserve-bytecode flag. Investigating.
I figured out what is causing the regression. It is the self-healing for function closures in the interpreter entry trampoline that is no longer kicking in. I am working on a fix.
The change in comment #4 should fix all regressions. I'll verify once the perf bots have picked it up and keep this issue open until then.
Status: Fixed (was: Assigned)
All graphs have recovered.
Project Member

Comment 7 by bugdroid1@chromium.org, Aug 22 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/7b8d760457e48cfc2be6658b0e99f7b0a7793c78

commit 7b8d760457e48cfc2be6658b0e99f7b0a7793c78
Author: bjaideep <bjaideep@ca.ibm.com>
Date: Mon Aug 22 18:34:35 2016

PPC/s390: [interpreter] Fix self-healing with preserved bytecode.

Port 4598d9139e5930543b55bca2154afc966b64c557

Original commit message:

    This fixes the self-healing mechanism for closures in the interpreter
    entry trampoline not that bytecode can be preserved even when baseline
    code is already available.

R=mstarzinger@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, mbrandy@us.ibm.com

BUG= chromium:638225 
LOG=N

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

[modify] https://crrev.com/7b8d760457e48cfc2be6658b0e99f7b0a7793c78/src/builtins/ppc/builtins-ppc.cc
[modify] https://crrev.com/7b8d760457e48cfc2be6658b0e99f7b0a7793c78/src/builtins/s390/builtins-s390.cc

Sign in to add a comment