This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I did a "Attach at Startup" option. Since that does not quite work right now, immediately after the connection was made, I went back to the "Modify Profiling" dialog and hit ok to get the instrumentation done. I then went to the menu choice to "Get Current Results". The result was I got the results, but the context was for a single thread, that somehow got randomly choosen. As a user, I expected that the results would have shown me the "All thread Combined" context first and then allowed me to choose a thread if I wanted to.
I agree with this request. We are currently considering getting rid of the threads combo and add an extra layer into the tree, so that it would look like: - CPU Results + Thread 1 + Thread 2 - Thread 3 - run () ... - foo () - bar () + Thread 4 And possibly a mode that would collapse the threads contents together so that all the matching call paths would be aggregated into one regardless of what thread executed them (JProfiler does this I believe). Jon, please let us know what you think.
I suspect (I may be wrong) that the real desire here is not to get data in the "all threads combined" form, but to see all the threads of the target application at once (and, of course, have easy access to all threads combined option). Since say 10 call trees at once won't fit the screen (at least with any useful data) you rather would like to see all the thread names and possibly some additional info like live/dead status. Do you agree with that? If yes, what do you think is a better option - a single tree containing all threads as nodes (you then expand them into the same call trees as you see now), or a tabbed pane with a separate tab for each thread, again containing the same call tree/flat profile as now?
Ok, it has been decided that we display all threads in one window, as a tree initially displaying just Thread nodes, where each node can be further expanded to see the usual method call tree for the given thread. More importantly, we take a single snapshot at the same time for all threads, contrary to the current mode where a snapshot is taken lazily for one thread at a time when the user selects it.
Changing to feature due to the scope of the issue, changing the summary to more clearly describe it.
Planned for M6
Increasing the priority to better reflect the importance and expected implementation timeframe for this feature.
Postponed till M7
Done, will be available in M7.
Verification of old issues.
Closing old issues.