Re: [linuxtools-dev] Tmf: a model to support new trace analysis types

[Alexandre Montplaisir <alexmonthy@xxxxxxxxxxxx>]

Hi Geneviève,

Interesting stuff! As we discussed previously however, "everything is an
analysis" is quite far from what we have currently in the framework.
Perhaps it'd be easier to go step by step, starting with introducing
experiment types.

Right now the trace type defines some of the elements you put in the
"analysis" (like state systems and custom statistics). It's also
possible to define a specific perspective (collection of views) in the
plugin for a trace type. (The framework could be improved wrt that, for
example automatically opening the perspective that matches the type of
the trace that is opened.) Even if you have two identical trace types,
but you want two different kind of analysis on them, this can be done
today by having two different trace types in the list. The user has to
make this decision at one point or another.

I just want to make sure that we have (ideally many) alternative use
cases and working examples before we start making big modifications to
the framework. If we dive in and start coding a big framework, most of
it might need to be rewritten when we get to integrating actual analyzes.

Some comments below,


On 13-07-12 03:43 PM, Geneviève Bastien wrote:
> Hello,
>
> As more and more trace analysis are getting available for TMF, I think
> we should have an easier, more modular way to add new analysis.
>
> From my experience with trace synchronization and execution
> graph/critical path, an analysis typically has to be implemented (a
> few more packages in tmf.core), it provides a view or more (in tmf.ui
> or the trace's .ui plugin), sometimes needs a handler for the project
> view (new classes in tmf.ui) and the trace needs to know about it
> (modification of the trace classes, even the ITmfTrace). tmf.core and
> tmf.ui are getting very crowded.
>
> Here's the analysis framework I'd propose to add new analysis:
>
> In tmf.core:
>   * A new analysis manager that handles the content from the extension
> point described below
>   * Base classes and interfaces for all analysis

Implementation detail, but do you intend on extending TmfExperiment for
this? Maybe the current TmfExperiment could be renamed to a more generic
"TmfTraceSet", and and Experiment would become a traceset with a
specific type given (like VM+host anlysis, etc.)

>   * ITmfTrace will have new methods to get all applicable analysis for
> a given trace type and execute them when necessary
>
> New extension point "org.eclipse.linuxtools.tmf.core.analysis"
> An analysis has
>   * class: Class that implements this analysis
>   * tracetype: class of the trace it applies to (default: all traces)
>   * requires: other analysis modules that are required to run before
> this one

Not sure this is required in the extension point. The trace type or the
analysis code itself can .waitUntilBuilt() / .waitForCompletion() on any
event requests, state systems, or other analyzes it needs.

>   * automatic: whether to run this analysis when the trace is opened
> (default: false)
>   * provided views: which views will be available once the analysis is
> done

This can be done with a perspective shipped in the analysis plugin. The
trace type or analysis type can then refer to it.

>   * icon: to represent this analysis


>
> The project explorer view could show the analysis like this for example:
> - My Project
>   - Experiments [1]
>     - SyncExperiment
>       - Trace 1
>       - Trace 2
>       o Analysis: trace synchronization
>         o Synchronization view
>         o Synchronization statistics view
>   - Traces [2]
>     - Trace 1
>       o Analysis: Lttng Kernel state system
>         o Control flow view
>         o Resources view
>       o Critical path
>         o Critical path view
> ....

The "mandatory" analyzes can be done today with how we handle trace
types (buildStatistics(), buildStateSystems(), etc.). The optional ones
however would be a new concept. Maybe we could have something like a
right-click menu option, "Apply analysis" -> "Critical Path analysis",
so the code is only ran when asked to do so. Or it could be done
automatically when the view is opened.

> In the long run, the actual state system and statistics could be
> considered analysis types and be refactored using this framework.

Not a big fan of this ;)  So far we've been able to keep everything
included in the trace type extension point. We should be able to do the
same with the experiment type extension point, short-term at least. It
prevents extension point bloat, and makes it easy to extend/modify
existing types by using OOP inheritance and polymorphism.

>
> Each new analysis can then be implemented in its own standalone
> plugin, with core and ui, which would require only the tmf.core|ui
> (and the plugins containing other analysis it requires of course). The
> main plugins would not require any analysis modules.
>
> I'd like some feedback on the proposed approach.  I know Francis
> Giraldeau has been thinking on this problem as well, mostly on the
> dependencies between analysis.  I think this approach is complementary.

Hope the feedback was useful. ;)  Let the discussions begin!

Cheers,
Alexandre

>
> Thanks,
> Geneviève Bastien
>