<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower"
href="https://bugs.webkit.org/show_bug.cgi?id=158906#c2">Comment # 2</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower"
href="https://bugs.webkit.org/show_bug.cgi?id=158906">bug 158906</a>
from <span class="vcard"><a class="email" href="mailto:fpizlo@apple.com" title="Filip Pizlo <fpizlo@apple.com>"> <span class="fn">Filip Pizlo</span></a>
</span></b>
<pre>This is fascinating! Here's what's happening: we enqueued a compile of <global>, which is a ginormous piece of global code, during the benchmark's unmeansured initialization phase. Then at the time that we try to compile search#, the JIT thread is busy compiling <global>. That takes a long time to compile and it generates a disgusting amount of code. <global> takes 16ms to compile and generates 8MB!!
There are a bunch of solutions we could attempt:
1) If we want to compile something and the concurrent JIT thread is busy then compile on the main thread instead.
2) Launch multiple JIT threads.
3) Delay the compilation of <global> based on size heuristics the same way that we do for DFG and FTL tier-up. This might be hard because I think that <global> actually spends a significant amount of time in its silly loop.
4) Don't compile all of <global> with the baseline JIT. It tiers up because of a tiny loop at the end.
I think I'll attempt (1). That seems like the easiest way of recovering this regression. I think it would be great to consider the other solutions, too.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>