The profiler currently records the bytecode at the time that it is first generated. But bytecode changes over time to incorporate profiling and inline caches. Currently the bytecode dumps already tell us: - the state of inline caches of heap accesses - the state of inline caches of calls And the bytecode dumps could easily also tell us: - slow path profiling data - value profiles One way to make this all useful is to enable the profiler to see the bytecode dumps at the time that the JITs were invoked.
Created attachment 178744 [details] WRONG PATCH
Created attachment 178745 [details] work in progress
Created attachment 178876 [details] sample profiling session This shows some of the changes that this patch makes. - You now see the instruction count in the full summary. - The full summary is now the default thing displayed when you run the tool (if you want the summary that just includes function names, source counts, and source, then use "s" or "summary") - New command, "profiling" or "p", which shows all of the profiling views that the JITs saw for each compilation that involved that code block. In this example I'm looking at a code block that gets inlined *a lot*. It's fun to see how the profiling "evolves" over time.
Created attachment 178879 [details] the patch
Landed in http://trac.webkit.org/changeset/137379