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.
When you exclude java.*, javax.*, sun.* classes it doesn't show any results of profiled application. To reproduce: - start to profile ColorPicker (Analyze Performance, Entire Application, All Classes) - wait until application is shown and move sliders a little - show current profiling results (there is something from examples.colorpicker package. Especially for AWT-EventQueue-0 thread e.g. greenSliderStateChanged() method) - modify profiling to exclude java.*, javax.*, sun.* classes - move sliders in the ColorPicker application window - try to show current profiling results but it shows only "No profiling results available yet." m2-rc3, WindowsXP, JDK1.5.0.
The problem is actually somewhere else. No data are collected unless one of the following happens: - the application execution reaches one of the root methods (in case of "Entire Application", the "public styatic void main (String[] args)" is the root method) - the application starts new thread && the "instrument spawned threads" checkbox is checked In any case, all of this is quite unintuitive, especially the use of main as the root method for Entire App profiling - the natural understanding people would have is that in case the whole app is being profiled, everything is instrumented and data for all code execution are obtained. This is all even worse when the "Modify Profiling" action is used and the Entire app CPU profiling is selected after the app is already up & running. In this case the results definitely do not match the natural users' expectations. This should be equivalent to a setting of Total instrumentation scheme, but only in case the main method is executed. Perhaps we should think about a class-load instrumentation for the Entire App profiling?
This issue has been reported by other users in different variations as well. Basically, the problem is that JFluid currently can start collecting CPU profiling data only when some thread enters (or re- enters) some "profiling root" method, that is explicitly defined by the user, or implicitly - by the tool. In "entire application" profiling mode, these roots are the main method and run() methods of all classes that extend Thread or implement Runnable. Thus if you modified profiling to "entire application" at arbitrary time, or attached to the running application and turned on this mode, you will in effect not see any profiling results until your application starts some new thread. You should use the "custom profiling" mode, and select some root method, e.g. your servlet's doGet(), or some other method that is an entrypoint into the code you are actually interested in profiling. An immediate remedy to this problem would be a warning dialog presented to the user when they do one of the above things, that would briefly explain what is explained at length above. The users whom I had a chance to discuss this issue seem to understand the general problem and agree that this measure would help a lot. Note that it's possible in principle, but rather non-trivial, to start collecting data when a thread is in arbitrary state. But for one thing, this may conflict with some carefully done performance optimizations in JFluid engine. Another issue may be about presenting the data that may have started to be collected when a thread had a deep stack, and start times for all of the methods on it were, naturally, unknown when collection started.
Fixed in M4, by displaying a warning message when the user switches to the entire app CPU profiling mode when the app is already running, as explained in the previous comment.
I suggest we keep this issue open, as the concept of "root" methods is still not entirely clear, and the UI needs to address that need more.
Ok, it looks like we came up with a solution when CPU data collection *can* actually start for a thread that is in an arbitrary state. However, since for this kind of "initial conditions" it is not possible to build a sensible call tree (because profiling may start when a thread already has a deep stack, and it can subsequently exit many methods for which entry hasn't been registered), it looks like in this mode we will only be able to collect a flat profile, plus, possibly, forward/reverse call graphs for individual methods. It remains to be seen how well this is going to work with our existing performance optimizations in the CPU data collection code - though the initial forecast is seemingly not bad.
Postponing to M5, will redo as part of tighter 4.0 integration, probably similarly to how Open Class works in 4.0
Correction for my last comment: postponing to M5/M6, we will further investigate the possibility to collect CPU results from arbitrary state
M6
Our investigation shows that when CPU profiling starts for a thread in an arbitrary state, we cannot collect a full CCT for it without incurring possibly very high overhead. That's due to the need to traverse the stack above the instrumented method that was entered from an unknown, uninstrumented method. This event can happen many times, hence the potentially very high overhead. We can, however, collect a flat profile with the same overhead as now, and that's what we plan for M6.
Changing to Enhancement, since this is not a bug, but rather new functionality, not available in any other tool.
Postponed till M7.
Will not be addressed in 1.0
Milestone cleanup: future->next
Addressed by implementing the sampling CPU profiler.