Bug 128047

Created attachment 222884 [details] work in progress

This is what it gives me. Notice how you can now see, at a glance, all of the reasons why a code block was recompiled. > log executeIteration Compilation executeIteration#BBg0Fw-1-Baseline: Compilation executeIteration#BBg0Fw-2-DFG: EXIT: at bc#87 due to InadequateCoverage, 1 times EXIT: at bc#123 due to InadequateCoverage, 2 times EXIT: at bc#649 due to InadequateCoverage, 1 times EXIT: at bc#179 due to BadFunction, 1 times Jettisoned due to BaselineLoopReoptimizationTrigger Compilation executeIteration#BBg0Fw-3-DFG: EXIT: at bc#1055 due to InadequateCoverage, 1 times Compilation executeIteration#BBg0Fw-4-FTLForOSREntry: Compilation executeIteration#BBg0Fw-5-FTL: Jettisoned due to WeakReference Compilation executeIteration#BBg0Fw-6-DFG: Compilation executeIteration#BBg0Fw-7-FTL: EXIT: at bc#79 --> checkIRQMatching#ENZlEebc#1 due to BadCache, 54 times EXIT: at bc#716 --> checkIRQMatching#ENZlEebc#1 due to BadCache, 25 times Jettisoned due to WeakReference Compilation executeIteration#BBg0Fw-8-FTLForOSREntry: Compilation executeIteration#BBg0Fw-9-DFG: Compilation executeIteration#BBg0Fw-10-FTLForOSREntry: Compilation executeIteration#BBg0Fw-11-FTL: Jettisoned due to WeakReference

It's even better when I add counts. Notice that you can now see some obvious stupidity going on here. Probably we're failing to hash-cons some crucial structures. > log executeIteration Compilation executeIteration#BBg0Fw-1-Baseline: Total count: 37692287 Max count: 444588 Compilation executeIteration#BBg0Fw-2-DFG: Total count: 2931054 Max count: 32885 EXIT: at bc#87 due to InadequateCoverage, 1 times EXIT: at bc#123 due to InadequateCoverage, 2 times EXIT: at bc#649 due to InadequateCoverage, 1 times EXIT: at bc#179 due to BadFunction, 1 times Jettisoned due to BaselineLoopReoptimizationTrigger Compilation executeIteration#BBg0Fw-3-DFG: Total count: 14441184 Max count: 169676 EXIT: at bc#1055 due to InadequateCoverage, 1 times Compilation executeIteration#BBg0Fw-4-FTLForOSREntry: Total count: 0 Max count: 0 Compilation executeIteration#BBg0Fw-5-FTL: Total count: 0 Max count: 0 Jettisoned due to WeakReference Compilation executeIteration#BBg0Fw-6-DFG: Total count: 29596525 Max count: 348302 Compilation executeIteration#BBg0Fw-7-FTL: Total count: 71610674 Max count: 843708 EXIT: at bc#79 --> checkIRQMatching#ENZlEebc#1 due to BadCache, 54 times EXIT: at bc#716 --> checkIRQMatching#ENZlEebc#1 due to BadCache, 25 times Jettisoned due to WeakReference Compilation executeIteration#BBg0Fw-8-FTLForOSREntry: Total count: 0 Max count: 0 Compilation executeIteration#BBg0Fw-9-DFG: Total count: 29435856 Max count: 346420 Compilation executeIteration#BBg0Fw-10-FTLForOSREntry: Total count: 375213 Max count: 4408 Compilation executeIteration#BBg0Fw-11-FTL: Total count: 323554095 Max count: 3810030 Jettisoned due to WeakReference

Created attachment 222892 [details] the patch

Comment on attachment 222892 [details] the patch r=me Not really clear what "Total count" and "Max count" mean.

(In reply to comment #5) > (From update of attachment 222892 [details]) > r=me > > Not really clear what "Total count" and "Max count" mean. Yeah. display-profiler-output currently uses "max count" for a lot of things. It means: if you count the number of times each bytecode instruction inside the machine code (i.e. it may include bytecode instructions inlined from other code blocks) has executed, then take the max of that. The benefit of max count is that it will typically tell you how hot the hottest loop inside the function is. Gavin never really liked the max and preferred the total, and we sort of agreed - 1.5 years ago? - that we would think this through more deeply and pick a better way of characterizing function hotness. Someone still needs to figure it out. So I just filed: https://bugs.webkit.org/show_bug.cgi?id=128053 For now, I'll just land this as is - more information is better. But yeah, it's important that we figure out what to do about this. I've just never seen a profiler get this quite right, so I don't have context for how to make the right choice, at the moment.

Looks like the Mac EWS failures are because I used "Project" instead of "Private" for the new header. Fixed.

Landed in http://trac.webkit.org/changeset/163254