|Re: [tracecompass-dev] Generic callstacks / callgraphs / flamegraphs|
Hi Alex, Thanks for reminding me what you're working on! :pIndeed 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" , 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  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"  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  https://git.eclipse.org/r/#/q/status:open+project:tracecompass/org.eclipse.tracecompass+branch:master+topic:%22for_jul_analyses+callstack%22
Back to the top