Re: [tracecompass-dev] Generic callstacks / callgraphs / flamegraphs

[Genevieve Bastien <gbastien+lttng@xxxxxxxxxxxx>]

Hi Alex,


Thanks for reminding me what you're working on! :p


Indeed there's definitely something there. I was planning for the 
CallStackView to use the new CallStack objects instead of the 
CallStackAnalysis and I was hoping that CallStack object could not 
advertise any state system related methods at all (a callstack _could_ 
be backed by something else than a state system). In which case the 
"StateSystemModelRenderProvider" name scares me, though maybe not its 
actual implementation.


But we can talk more when I look at your work and put a bit more thought 
to the 'how' of the callstack/callgraph implementation. For now it's 
just ideas and RFC after working a bit on it.


Cheers,

Geneviève


On 09/09/16 01:43 PM, Alexandre Montplaisir wrote:
> Hi Geneviève,
>
> As you know, I am currently working on generalizing the time graph
> views, by splitting the view model from the presentation layer. My first
> target is the Control Flow View (and probably the Resource View at the
> same time, since it's based off the same data). But I can easily see the
> Callstack view fit into that model, since it is just a specialized
> statesystem-based time graph view.
>
> Your ICallstackProvider could become a subclass of
> "StateSystemModelRenderProvider" [1], which would then populate its
> corresponding Callstack View. This would avoid duplicating all the
> view's logic. Then ICallstackProvider could provide all the downstream
> flexibility you want. It would also be a good occasion to make sure the
> *ModelRenderProvider classes provide sufficient functionality.
>
> I should have a prototype ready over the next week, we can discuss it
> further at that point.
>
> Cheers,
> Alex
>
>
> [1] WIP prototype (lots of fixmes etc. remaining):
> https://github.com/alexmonthy/tracecompass/blob/426a9026e405465c7e24cc5e50a4d3c2eb19f14c/tmf/org.eclipse.tracecompass.tmf.core/src/org/eclipse/tracecompass/internal/provisional/tmf/core/views/timegraph2/statesystem/StateSystemModelRenderProvider.java
>
> The implementation for the Control Flow would look like something like this:
> https://github.com/alexmonthy/tracecompass/blob/426a9026e405465c7e24cc5e50a4d3c2eb19f14c/analysis/org.eclipse.tracecompass.analysis.os.linux.core/src/org/eclipse/tracecompass/internal/analysis/os/linux/core/views/controlflow2/ControlFlowRenderProvider.java
>
> (note that both of these are *core* classes, no UI dependencies at this
> level!)
>
>
> On 2016-09-08 09:52 PM, Geneviève Bastien wrote:
> > Hi all,
> >
> > Callgraphs and flamegraphs were added recently to Trace Compass. This is
> > such a great news that I want it for all my analyses!!
> >
> > Some use cases: sql queries and functions calls for a web request,
> > execution stacks of threads used by the views of Trace Compass, a
> > user-defined callstack from a ust-trace.
> >
> > So in the next weeks, I'll be working on making callstacks and
> > callgraphs and their associated views more generic. I have a few patches
> > on gerrit under the topic "for_jul_analyses callstack" [1] but they are
> > not quite ready for review. Here is the plan:
> >
> > 1) Add a ICallStackProvider interface, implemented by the current
> > CallStackAnalysis class that will provide CallStack objects that will
> > describe where to get the callstack from [in the state system for now]
> > 2) Make the CallGraphAnalysis use those ICallStackProvider and their
> > CallStack(s) instead of the CallStackAnalysis directly and make sure all
> > the views still work.
> > 3) The current call stack analysis has a hierarchy process ID -> thread
> > ID -> callstack where process IDs and thread IDs are conveniently
> > integers. But that does not cover all the use cases. So instead there
> > will be levels of grouping where a callstack can have as many levels as
> > it wishes. The current case would have 2 levels (Process and threads)
> > along with the final callstack level that has to be there. The current
> > callstack will still work as it does now with the symbol resolution.
> > 4) Add support of XML-defined callstacks, where an XML analysis will
> > fill a state system with callstack-like data and will provide it as
> > callstack to the views.
> > 5) Fix the flame graph so that there is more than one level of grouping
> > that can be shown (now is only threads, we don't have the process level)
> > 6) Make it possible for callgraph to use any of the levels for
> > aggregation, as requested by the user (right now, statistics are
> > aggregated per thread only)
> >
> > 1 and 2 are done, as well as 4, but it lacks 3 to be entirely
> > satisfactory. Any thoughts? Comments? Additional requirements?
> >
> > Best regards,
> > Geneviève
> >
> > [1]
> > https://git.eclipse.org/r/#/q/status:open+project:tracecompass/org.eclipse.tracecompass+branch:master+topic:%22for_jul_analyses+callstack%22