Status: Accepted
Owner: ----
CC: [email protected], [email protected], [email protected],
[email protected], [email protected]
Labels: Type-Bug Priority-Medium
New issue 2139 by [email protected]: Long compilation times and frequent
deopt/recompile cycles with large methods
http://code.google.com/p/v8/issues/detail?id=2139
http://crbug.com/128252 describes a problem with an Emscripten-compiled
library (the Bullet physics engine) where during startup the demo exhibits
extremely slow startup.
Bisecting yielded the V8 3.9.3 roll as the likely culprit:
-----
You are probably looking for a change made after 120825 (known good),
but no later than 120849 (first known bad).
CHANGELOG URL:
http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=120825%3A120849
-----
Initial investigation indicated that after this roll, some large methods
that previously weren't compiled are being compiled, and the compilations
were taking hundreds of milliseconds. Compare the disposition of
methods "o" and "Em" in the attached files compilation-log-r120523-good.txt
and compilation-log-r120954-bad.txt .
It looks like changes between r120954 and current Canary (r137350) cause
these methods to be deoptimized and recompiled many times during
application warmup, exacerbating the problem.
fschneider and vegorov suggested the following avenues of investigation:
- What phase of compilation is taking so long
- Propagating type information into the non-executed portions of
Crankshaft-compiled methods; this could probably at least help with
Emscripten-compiled code, which uses typed arrays heavily
- Better throttling of deopt/recompile cycles in particular for large
methods
Attachments:
compilation-log-r120523-good.txt 15.2 KB
compilation-log-r120954-bad.txt 15.4 KB
compilation-log-r137350-canary-bad.txt 124 KB
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
