<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - Web Inspector: type profiler does not dim functions that were never called"
href="https://bugs.webkit.org/show_bug.cgi?id=140962#c5">Comment # 5</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - Web Inspector: type profiler does not dim functions that were never called"
href="https://bugs.webkit.org/show_bug.cgi?id=140962">bug 140962</a>
from <span class="vcard"><a class="email" href="mailto:sbarati@apple.com" title="Saam Barati <sbarati@apple.com>"> <span class="fn">Saam Barati</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=140962#c4">comment #4</a>)
<span class="quote">> (In reply to <a href="show_bug.cgi?id=140962#c3">comment #3</a>)
> > The problem here is that when the inspector first opens with type profiling
> > enabled (or the user turns type profiling on mid-way through inspection),
> > JavaScriptCore has an incomplete view of those functions that have run and
> > those functions that have not run. Because of this, JavaScriptCore won't get
> > completely accurate information until the page is refreshed.
> >
> > The approach to this problem is two fold:
> >
> > 1. We're going to switch the default to be from assuming a function has run
> > to assuming it has not run. This doesn't solve the problem, but it is less
> > misleading and probably a better default.
> >
> > 2. We're removing gray backgrounds of unexecuted basic blocks and instead
> > are going to lessen the saturation of the syntax highlighting on these
> > unexecuted blocks. Again, this doesn't solve the problem, but provides a
> > more subtle UI that is less obviously misleading. It is also more pleasant
> > to use.
> >
> > In the future, we can solve this more directly by at least considering
> > enabling JavaScriptCore's /runtime/FunctionHasExecutedCache class to be
> > enabled at all time and not only when the type profiler or control flow
> > profiler is enabled.
>
> What's the state of this bug today, Saam?</span >
So we implemented (2) a while ago.
I tried implementing (1) and unfortunately there is a dependency between
the way the control flow profiler works and the way we display the UI.
Basically, the control flow profiler is broken for programs with very
weird control flow and how that interacts with how we generate control flow
in JSC's bytecode. It's probably worth fixing this. I'm not sure what the solution
is. I remember looking into this a year ago but I gave up at some point
because I kept running into bugs. I'd be happy to look at this again at some point.
It probably requires completely rewriting the control flow profiler to be
tolerant of how we emit code in bytecode not aligning well. Maybe we should
rewrite it to be an analysis over bytecode basic blocks and then correlate
the bytecode basic blocks back to basic blocks in the JS program.</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>