Community
Participate
Working Groups
It would be nice to be able to filter what is displayed in the multicore visualizer. As it is, the visualizer always shows all CPU(s) and cores that are detected. It also shows all the threads that are part of the program being debugged. There are situation where the user might want to focus his attention on a specific subset of the CPUs/cores/threads. Filtering what is being showed in the visualizer might be useful in those cases.
Created attachment 229921 [details] Example of filtering based on threads Here we see the "before" state where two threads are selected. Then the filter being applied, and the finally the result.
Created attachment 229922 [details] Example of filtering based on cores In a functional setup with 4 CPUs each having 4 cores, one core from each CPU is selected and then a core filter is applied. In the capture we see the before and after canvas.
Created attachment 229923 [details] Example of filtering based on CPU Here we have 4 CPUs. We select 3 and apply a CPU filter.
Hi, I will soon submit a patch for review, that adds a canvas filter to the multicore visualizer. The basic idea is the following: In the visualizer, one can select threads, cores and CPUs. (once bug Bug 404894 is merged). When some of those are selected, new entries will become enabled in the context menu, permitting the creation of a display filter, based on one type of selected objects. With the filter created, only the objects that of that type, that were selected at filter creation, will be displayed. Objects of other types that have a relation will then selectively be shown: - a CPU filter will show the chosen CPU(s), all their cores and threads - a core filter will show the selected core(s) on their respective CPU(s) and their threads; CPUs with no core selected will not be shown. - a thread filter will show the selected thread(s), the core(s) they run on and the CPU(s) the core(s) belong-to. CPUs and cores with no shown thread will not be shown. When a filter is active, a "Clear filter" entry will be active in the context menu. ATM I only permit one filter level; one must clear a current filter before applying a new one. Some code-level highlights: MulticoreVisualizerEventListener: - in handleEvent(ISuspendedDMEvent): the call to requestUpdate() was not sufficient in the case where a filtered-to thread that had just stopped had changed core; the old core would still be displayed, without that thread. So I replaced the call by a call to MulticoreVisualizer.refresh(), which calls canvas.requestRecache() and canvas.requestUpdate(). Created new class: MulticoreVisualizerCanvasFilter: there is the filtering logic. MulticoreVisualizerCanvas: - in the canvas refresh code and paintCanvas(), where graphical objects are built from the model, the filter is asked for each object if it should be displayed; if not we do not create the graphical object (and so it's not displayed). One consequence of that is that filtered-out threads will not be sync'ed to and from the debug view. - With filtering enabled, it's now possible (or more likely) to have multiple CPUs displayed that have a different number of cores. The old code did not always work correctly in that case, so it needed updating. I went for an easy solution, where all cores have the same size. A more complicated alternative (and arguably not necessarily better) would be that each CPU had its cores sized to maximize space usage, or maybe have CPUs be a different size depending on the number of displayed cores. I will attach two screenshots of the canvas to illustrate what the currently implemented solution looks-like, before and after applying a filter on selected cores. Opened questions: - should a filter stay in place if we change the debug session (switch between sessions / kill session / start a new session)? If a filter is set on thread id(s), switching session will result in a blank canvas, which might confuse the user. OTOH if the filter is set on CPU(s)/core(s), the user might expect the filter to stay in place when switching session. Not sure which is more annoying. ATM I clear the filter when a new model is assigned to the canvas, in MulticoreVisualizerCanvas.setMode(). This could easily be removed. - Should there be a visual clue that a filter is in place? In some cases, a filter might come to filter everything and show a blank canvas (for example filtering on a single thread that then exits).
I have pushed the patch: https://git.eclipse.org/r/12138
w/r to the patch submitted in this bug, I declare the following: 1) that I am authorized to submit this code change 2) that the code is 100% my own work Marc Dumais
The patch set has been merged.
