Difference between revisions of "CDT/Obsolete/MultiCoreDebugWorkingGroup/VisualizerView"

Revision as of 15:51, 31 January 2011

Visualizer View

This article presents a proposed debugging view for the Eclipse IDE, known as the Visualizer View.

A bugzilla entry has been created to track the progress of this effort:
Bug 335027: Visualizer View feature

Overview

The existing Debug View in Eclipse consists of a simple tree structure, displaying launches, processes, threads, stack frames, etc. in creation order. The Debug View allows selection of a process or thread of interest, and allows actions to be performed on the selected entity, such as suspending or stepping. The Debug View also serves as a selection source for other views: a selection in the Debug View triggers updates in the source code view, variables view, etc.

This presentation is suitable for the very common case where the developer of a multicore application views that application merely as a "bag of processes" and does not really care how they are scheduled on the physical hardware, beyond perhaps ensuring that multiple worker processes are not competing for the same resources.

There are other possible presentations, however. These include:

1. a more concrete view, where the actual layout of tasks on hardware is shown
2. an application-centric view, where the layout is a graphical representation of the parent/child or functional relationships between tasks
3. other possibilities, which require more than a simple flat (or hierarchical) listing of tasks

These presentations, or visualizations of debugging state, suggest the need for a Visualizer View, which can be used to present and possibly select from the available visualizations.

This Visualizer View should not be viewed as a replacement for the Debug View, but rather as a complementary perspective on the same application. To give an analogy, in writing a technical article one does not dispense with the text of the article and merely present a graph; one uses the graph to cogently present an overview of the details discussed in the article. Similarly, the Debug View might still serve as the "main view" of a debugged application, but one might also use the Visualizer View to get a different, high-level perspective on the same application.

In creating any such visual presentation of debugger state, one needs to

1. present an overview of large numbers of elements in a compact, yet accessible form
2. make important things (e.g. suspended/crashed processes) stand out, while giving a clear sense of the overall state (e.g. all other processes are fine)
3. allow the user to select and interact with these elements in a straightforward way

Tilera's Grid View

A specific example of a concrete, hardware-centric visualization is the Grid View extension added by Tilera Corporation to its Eclipse-based IDE.

The figure below is a screenshot of the Grid View, showing an application that consists of a number of processes distributed across "tiles" (or cores) on Tilera's chip. The tiles are indicated by the squares in the grid, hence the name "Grid View", and the processes/threads by colored "dots" within the squares. Each process/thread "dot" is further annotated with its Linux task ID. (Not shown is a tooltip displayed when one hovers over a tile or process, providing further detail such as the executable name.)

In this example, the application is stopped at a breakpoint (hence the overall yellow coloring of the hardware elements) and one process has "crashed" by raising a signal. (This is the process "dot" on the red tile with the blue selection ring around it.)

Other elements to note in the Grid View display are:

• the I/O and memory elements around the edge of the grid
• the task (x,y) coordinates indicated at the top and left edges
• the overall application state, displayed as text at the top

As noted above, the Grid View does not replace the Debug View. Rather it complements it, by presenting a hardware-oriented view of the layout of the application. In the Tilera case, it might happen that the arrangement of processes on tiles, or their proximity to various I/O devices is of interest. At the very least, the Grid View provides a quick visual confirmation that there is at most one "worker" process scheduled to a tile. (On the red tile, the parent process and a worker it has forked are momentarily sharing the same tile.)

The Grid View also allows selection of processes/threads. In the figure above, in the top-right corner two processes are being drag-selected using the marquee-style selection box. The view's toolbar buttons for pausing, stepping, etc., mimic the corresponding buttons on the Debug View, and apply to the currently selected process(es). (More precisely, they correspond to processes that have an associated debugger, indicated by a small "D" mark next to the process.)

Finally, the Grid View also serves as a selection source for other views. The selected process(es) or threads in the Grid View are automatically selected in the Debug View, and views that are dependent on the Debug View selection are implicitly updated as well. Similarly, the Grid View is "selection aware", so a selection in the Debug View causes the Grid View to update its selection accordingly.

This is an example of a useful synergy between the two views: in the Debug View it is not immediately obvious which process is assigned to which tile, but by selecting a process in the Debug View, one can immediately see from the selection in the Grid View which tile it is currently associated with.

Use Cases

Hardware Types

The potential hardware/application types that would want to be supported by this framework are:

1. A highly symmetric, many-core platform with a specific 2-D hardware layout, such as Tilera's chip.
2. A symmetric, many-core platform with a large number of cores, where the layout is not essential -- in other words, a generic parallel display.
3. An asymmetric, SoC hardware platform.
4. Possibly multiple hardware components ganged together.

TBD: Suggestions are welcomed, as well as more detail on the
latter cases, as the author's background is heavily biased towards
symmetric and massively parallel hardware platforms!

Debugging Tasks

The guiding debugging tasks for this proposal are:

- Default Visualizer View state:

  - The Visualizer View can exist when there is nothing to be displayed.
    In such cases, it should have some initial "default" display,
    for example, a blank view or perhaps a guiding message. ("Please invoke
    a launch", etc.) This can be left to each of the selectable presentation(s),
    but this case should be taken into consideration in the design of any
    such presentation.

- Debugging a multi-process/thread application in a symmetric environment:

  - When the user launches an application, the Visualizer View should
    update to reflect that launch. Note that the launch does not have to
    be invoked in Debug mode -- the Visualizer should work just as well
    for non-debugged applications.

  - During execution, with some periodicity, the Visualizer View should
    update to reflect the current state (or at least a snapshot) of the
    application as known to Eclipse/GDB at the time. There will necessarily
    be some skew, but this is permitted, since the goal is to allow a rough
    sense of where the application is.

  - The Visualizer (or rather each presentation) indicates somehow
    which of the visible elements can be operated on by debugging actions.
    This might be a marker of some kind that shows where debuggers are attached.

  - When execution is suspended "normally" (e.g. at a breakpoint)
    the Visualizer should update to reflect the current state. At this point
    we want the presentation to be as current and accurate as possible.
    If we're debugging in an environment where some processes are allowed
    to continue execution, it is permissible for only the suspended processes
    to be up to date, and the rest are displayed based on their last
    reported state.

  - When execution is suspended due to a crash,
    the Visualizer should update to reflect the current state.
    The crashed process(es)/thread(s) should be indicated.

- Switching between launches

  - When the user changes the launch context (i.e. by selecting a different
    simultaneous launch in the Debug View) the Visualizer View should update
    to reflect the selected launch's state.

  - When a launch is removed from the Debug View, if it happens to be the
    one displayed in the Visualizer View, then the state of some other
    launch should be displayed. (Which one to display is somewhat arbitrary,
    but it is suggested that it should be the next most recently viewed
    launch.) If no other launch is available for display, the Visualizer View
    should return to the "default" state of the currently selected presentation.

- Selection in the Visualizer View

  - The user selects a set of debuggable elements (e.g. processes/threads)
    in the Visualizer view. The Debug View selection updates as a result,
    causing its dependent views to likewise update.
    Where more than one such item is selected, the item selected
    in the Debug View is arbitrary.

  - If selected items in the Visualizer View do not directly correspond to
    Debug View elements (for example, if the user selects a tile), then
    related Debug View elements are selected (for example, the process if
    any that is currently on that tile).

- Selection in other views

  - The user selects a process, thread, etc. in the Debug View.
    If this corresponds to one or more elements in the current Visualizer View,
    then the view updates its own selection accordingly. If no such elements
    exist in the visualization, the selection there is cleared.

- Actions on selections

  - The user selects one or more processes, and clicks, for example,
    "Suspend" in the Visualizer's toolbar. This should be the same as
    invoking the Suspend action in the Debug View for any process(es)
    that have debuggers associated with them. Processes that do not have
    debuggers are unaffected by the command. (A possible alternative
    is attaching debuggers to any such processes, but this may involve
    too much overhead to be practical.)

- Context Menu support

  - If the user right-clicks on the Visualizer View, the click location
    is used to determine the contextual item, if any. For example, the user
    may right-click a tile or a process/thread icon. (Alternatively, the
    current selection, if any, is treated as context.) A context menu with
    appropriate commands for the context, plus any "global" actions,
    is displayed.

- Switching between presentations

  - The user runs an application, and selects items in the current
    Visualizer presentation. The user then switches (via tab or other control)
    to a different presentation. The new presentation should update
    (or already be updated) to reflect the current launch and the
    current selection if any.

Requirements

The Visualizer View, as here proposed, should not be thought of as a specific visualization, such as the Grid View, but rather as a framework. The Visualizer View should support multiple graphic representations of the current state of an executing application, and allow selection of items and invocation of actions on that application. It should also allow the user to easily switch between the available views.

Note: An alternative model to consider would be multiple views, one for each such presentation. However, since the visualizations are of the same debugging target, and there would be a great deal of overlap amongst these views, we are proposing a single view, multiple-presentation model here.

As noted above, a given visualization can be highly concrete, e.g. an exact representation of the processing hardware showing the layout of the application on it, as in Tilera's Grid View. It could also be highly abstract, e.g. a graph representation of the processes/threads of the application, showing their parent/child relationships.

One important motivating instance of this is displaying and allowing control of an application with one or more debuggers attached to its processes. So for example in the Grid View, a marker (a small "D") is used to indicate processes with associated debuggers, and the toolbar operations of the view are oriented towards control of these debuggers (stepping, suspend/resume, etc.)

Something else to note is that we distinguish visualization views (such as the Debug View or the Grid View) from detail views (such as the Variables View, the Memory and Disassembly Views, etc.) which provide detail or related context based on the current selection. The intent of a visualization is to provide the "big picture", while detail views like those indicated above provide a narrower, focused view of the selected element. (This is a broad classification, and it's not impossible that the selected element could itself be complex enough that such "detail views" might themselves require some kind of visual representation, but for now we exclude this possibility.)

The Visualizer view should consist of:

- The Visualizer view itself. This should support periodic and on-demand
  updating of the display, in response to:
  - user actions, like resizing the view</li>
  - event(s) from the model ("push" model)</li>
  - periodic updating of the view ("polling" model)</li>

- A provider-based "presentation" mechanism for display of the model,
  its elements, and their current state.

- An application-specific "model" object hierarchy.
  Ideally, this is just the application model itself, i.e. objects representing
  processes, threads, tiles, etc. The model classes themselves should be
  entirely presentation-agnostic. The presentation model is responsible for
  the mapping from model to view elements.

- A description of the target, in a presentation-neutral format, which
  captures any important layout information that would be useful.
  (The internal structure of the hardware, connections between elements, etc.)

- An update framework for reflecting changes to the model state.
  Examples:
  - rescheduling of threads to new tiles
  - changes to thread state (running, paused, stopped at breakpoint)
  - generated model state (e.g. current processor cycle,
    aggregate amount of memory in use, other on-the-fly performance data;
    in general stuff that isn't associated with a specific event, but wants to be
    periodically updated)

- Some kind of "backend" interface, by which the presentation can receive
  information about the target and its current state.
  (This may serve as a source for the target description and update
   information described above.)

- An action framework for performing operations on the model and its elements.
  Examples:
  - stopping/starting debugged processes</li>
  - attaching a debugger to a process on demand</li>
  - opening a console pane associated with a specific process</li>

  The action framework should support not only toolbar items for the view,
  but context menu items displayed on the Visualizer View's context menu.

- A context menu mechanism, by which context menu items can be registered
  "globally" (e.g. for the view as a whole) and presentation-specific items
  added on the fly, based on the right-click context and/or the current selection.

- Other requirements:

- Support for multiple different user-selectable presentations
  (e.g. a hardware view vs. a more abstract "application" view).

- The ability to select element(s) of the model and have that selection
  be made available to the workbench as a whole, and via the Debug View
  selection mechanism in particular. (Note: this probably requires defining
  some mechanism for mapping visualization elements to objects that are
  "known" to other views, such as debug targets, processes, etc.)

- Acceptance of selection state provided by the workbench, and auto-selection
  of corresponding elements (if any) in the visualizer view.

- The Visualizer View should support pin-and-clone, so a user can have multiple
  views open, each pinned to a given launch and presentation.

Proposed Implementation

Visualization Framework

The visualization framework will want to include the following classes:

. VisualizerView
  - This is a standard "singleton" Eclipse view, which contains a viewer and
     actions, and interacts with the workbench as usual
  - Question: do we actually need this, or can we assume the user will
    create their own view (i.e. the "Grid View") and use the classes below?
    For the Grid View, the outermost view mainly handles toolbar actions
    and the context menu.


. VisualizerViewer
  - A "canvas" style control that displays the view contents of the
      currently selected presentation
  - Should be arbitrarily scalable in width/height.
  - Should decide when to update itself based on user resizing, etc.
  - Should provide a method for requesting an update, and "batching" requests
    (e.g. by using a timer to periodically check whether an update is needed)
  - Should also support tool-tip display
  - Events:
    - move move/drag (to allow rubber-banding/marquee display)
    - point/region selection
    - element selection (using providers to decide what got selected)
    - context menu action
  - Question: who creates the viewer elements? Does the presentation decide
    what represents what, or does the view "walk" the presentation view of the
    model and assign one element to each walked child?

. VisualizerViewerElement
  - Graphic display element, base class for view elements of various presentations
  - This is not a UI component, it is simply a class that knows how
    to draw itself given an appropriate graphic context from the VisualizerViewer.
  - Viewer (or rather current presentation) sets the bounds of this element
    based on its own size, then the element decides how to draw itself
    within the space it's given.
  - One could also abstract out scaling of elements to the canvas, but in general
    the result looks uglier than if an element draws itself based on its size and
    can decide when to simply stop displaying labels, details, etc. because
    it is being drawn too small.
  - should provide methods for
    - determining whether a click point is contained in the element
    - determining whether a selection region contains/overlaps the element

. VisualizerPresentationManager
  - Manages set of presentations for VisualizerViewer
  - Question: how is a presentation selected? Should the selection UI (if any)
    be part of the presentation itself, so it can be defined by the user?
    Or should we provide a tab panel, etc. mechanism, like in the Memory view?

. VisualizerPresentation
  - Represents one possible display of the current visualizer model
  - Includes methods for obtaining the model object and navigating its structure.
  - Provider based, consults list of VisualizerPresentationProviders to
    find one that knows how to present the current object.
  - Provides context menu actions for the presentation as a whole

. VisualizerPresentationProvider
  - Presentation for an element (the whole platform or one of its hardware elements, etc.)
  - Knows how to present the element itself, given its size.
  - Provides methods for accessing the element's parent/children.
  - Provides any element-specific context menu items
  - This allows the model object to be an arbitrary tree-structure, perhaps
    even the existing object model, with no need for an extra "model" hierarchy.
  - It also makes changes to the model easy -- just add a provider for any
    new object type.

. VisualizerContextMenuManager
  - Manages construction of context menu for Visualizer View
  - allows registration of "global" context menu actions, always displayed
  - polls the current presentation dynamically for any additional,
    context-specific actions to present

. "Visualizer Model" Object
  - Root class of tree structure representing platform, etc. to display
  - This can be any object, the VisualizerPresentation encapsulates how
    it is navigated and presented.

. A "model descriptor" data structure that captures important aspects
  of the target platform's layout (core "grid", IO devices, etc.)
  This should be in a presentation-agnostic format, and serves as a guide
  for presentations that want to provide a realistic hardware layout.
  A presentation is permitted to summarize, paraphrase, or ignore this
  information as needed, based on what it intends to show.

. A "backend framework" by which the model and/or presentation can receive
  updates on the target's state. (This might include the model description
  noted above.) Note that this framework should not be directly tied
  to the visualizer view -- ideally, the backend informs the model, and the
  model (though appropriate update events) triggers an update in the view.
  We do need some standard framework by which a given target can tie its
  backend into the visualization mechanism.

"Hardware Visualization" Instance

It is suggested (though not required) that the Grid View, or a similar hardware-oriented view, should serve as a specific, motivating example of a visualization style to be supported by the above framework.

Since there is no one "right" visualization for all possible hardware types, what might be required is either:

• a prototypical example that could be modified or extended to suit the hardware layout(s) in used by a particular implementer.
• or a generic "hardware view" that supports some kind of description language that specifies the layout of elements and identifies them for the purpose of assigning update events to them

(TBD: Need more detail here -- use cases welcomed!)

Implementation Considerations / Design Choices

For the Visualizer view and element classes, we might consider specifying/using a plugin that provides graphic elements and view support, for example GEF (http://www.eclipse.org/gef/) to reduce the coding needed to construct a presentation.

However, this has the consequence of making that plugin a requirement for CDT and/or base Eclipse, so we'd need to be sure it was the "right" one. There is a precedent for this: the remote launch plugin requires RSE.

Perhaps the Visualizer framework may not specify or require such a plugin, but a specific visualization instance, such as the Grid View, might do so.

Alternatively, we might have the framework leave the choice of implementation entirely open, and provide some useful examples in various frameworks like GEF to show what's possible.

TBD: Does the Parallel Tools Platform (PTP, http://www.eclipse.org/ptp/) have a similar view, and/or is there any possible synergy here?

Comments To Be Factored In

If you have comments, please add them to the bugzilla: Bug 335027: Visualizer View feature