Future use cases

Grouping threads from different processes within the same debug session.

Adding a node to a existing group.

Renaming group.

Persisting groups between debug sessions.

Adding a breakpoint to a group.

Groups belonging on the back end.

Design bits and pieces

Which debuggers can have grouping feature?

By default grouping of debug elements is disabled. The command group “Debug View Layout” needs to be enabled from the perspective customization dialog.

The grouping feature is available only for DSF debuggers that implement IExecutionContextTranslator.
Currently GDB is the main drive for the grouping feature. Its implementation is available from the latest patches in https://bugs.eclipse.org/bugs/show_bug.cgi?id=336876
Even after applying the patch the user has to set an environment variable GDB_DEBUG_VIEW_GROUPS to 1 to use the feature.
Once the basic features in the GDB implementation is acceptable and commited a second DSF debugger will also be integrated. That will help to extract the common pieces from GDB-DSF to DSF.

The UI actions are contributed in CDT UI so in theory CDT-CDI can also implement grouping on their own.
Considering that the CDT-CDI is based on fixed hierarchy and it is mostly in maintenance mode I doubt anyone will go ahead and implement groping there.

Currently the IExecutionContextTranslator interface is experimental.
It is defined as minimal functionally so the group and ungroup command can be hooked up as soon as a DSF debugger implements that service.

What does the back end control (will control)?

Currently GDB doesn’t have the concept of groups on the back end.
The user defined groups will iterate through its threads to run/suspend/show running state, etc.
With other DSF debuggers that behavior can be different – the groups can belong to the back end and the back end can dictated how a resume / suspend operation is to be executed, how will the running state be aggregated.

Recreating the execution context under different parent’s hierarchy.

When we group execution contexts we recreate the execution context again with one if its immediate parents – the newly created group.
Since the parents are part of the object’s identity that means that clients that cache the execution context will need to point to the new objects after the group is created.
Alternatively instead of caching the execution object it is better to cache the real object it represents – in the GDB case this is the ThreadDMcontext.
GDBRunControl_7_0_NS is an example of component that has been reworked to cache MIThreadRunState against the IThreadDMContext instead of the IExecutionDMContext.
To unify what should the client cache instead of the execution context I introduced the function IMIExecutionContextTranslator.getStableContext().
Also the CommandCache is replaced with a new class MICommandCache that underneath calls IMIExecutionContextTranslator.getStableContext().
If DSF components need to change what they cache this function will move up IExecutionContextTranslator, no need yet.
Alternative approaches have been discussed at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=336876#c24

Introducing IRunControl3.

IRunControl has synchronous methods isSuspended() and isStepping(). In order for the group to figure out if any of its children is stepping or suspended it needs to get the list of its children which is an asynchronous API. Therefore DSF debuggers that support grouping also need to implement IRunControl3 which just define isSuspended() and isStepping() in asynch way. All places in DSF that use these function should switch to using the asynch version, at least in the case of the container DM context.

Propagating the changes in debug view layout.

Considering that grouping is part only of bigger feature – debug view layouts currently there is only one event introduced to communicate that there was a debug view layout change. As introduction of more feature ( hiding, full layout ) more specific event can be added.
The event IContainerLayoutChangedEvent inside the interface IMIExecutionContextTranslator.

Introduction of AbstractExecutionContextVMNode

There are many similarities between AbstractContainerVMNode and AbstractThreadVMNode. AbstractExecutionContextVMNode is a base class that will host the shared functionally. Currently the function there are not hooked up to the immediate derived abstract classes, but only by the concrete instance in GDB – ContainerVMNode and ThreadVMNode. As other DFS debugger start implementing grouping this class may enclose more common functionality.

Changes to DefaultVMModelProxyStrategy to support generating deltas for recursive VM Nodes.

The changes are 100% compatible. Only if the user calls setAllowRecursiveVMNodes() the new implementation will take effect.
Originally DefaultVMModelProxyStrategy didn’t accept recursive container for generating deltas, even though they are accepted and supported by AbstractDMVMProvider for viewing. The approach I took is to support recursive container in delta generation is to have the VMNodes to generate level by level its deltas instead of one the whole delta at once.
That required changes in indentifying which is the correct context for each of the events.