There are times where I don't want any class instrumentation or redefinition whatsoever -- just simple "collect a thread
dump every 10ms and aggregate the data" profiling for the whole app.
NetBeans has a good profile results UI, etc, I shouldn't have to switch to a different tool in cases where I want
simple, low-fidelity (but relatively quick) sampling profiling. This is especially true since the dynamic attach with
Java 6 is compelling and other profilers don't yet have this. Also there are still cases where a bug in Java 6 causes
the target JVM to crash when the profiler asks it to redefine classes, which sampling should work around -- though even
without this bug there would still be a time and place for sammpling-based profiling.
This is also quite relevant if the "VisualVM" project (https://visualvm.dev.java.net) that was shown in a BOF at JavaOne
2007 is ever to come to fruition in this area. Most people expect both an instrumentation and profiling mode from any
Obviously the NetBeans team can disagree, but I'd posit this as a top-priority enhancement for NB 6.1.
In fact till this feature is not in NB Profiler I can't continue "trying" it.
I should be clear that I *need* this feature because I work with a system that is too large to instrument in its
entirety -- it not only takes forever but the NetBeans profiler says something about having exceeded its limits on
instrumented classes/methods and gives up!
It is impossible to know the root methods to target up front in all cases -- even when you know the system well as
sometimes you don't know the problem well. If you don't know the system well, then you're really sunk.
A lightweight, low-fidelity sampling mode could allow the hotspots to be narrowed down enough to allow configuration of
root methods. As it is now one is often just plain sunk and realistically has to use another tool.
A scaled down version of this feature should be built into NetBeans itself for purposes of allowing users to report
performance issues against NetBeans. Currently NetBeans users gripe about performance but have trouble providing
sufficient data for NetBeans developers to do anything about the problem. If there was a simple, "start/end performance
sampling" control for this where the data could be attached to a bug report, performance complaints could be addressed
much more readily.
This scaled down version could be as simple as taking a full stack dump every 'n' seconds and doing some string
canonicalization and compression to keep the data size down. Further processing could be postponed until a simple
analysis tool for use by NetBeans developers.
In the context of something like VisualVM, this scaled down version could be a really big boon for other products beyond
NetBeans, i.e. my customers could use the same thing when complaining about my products' performance.
(In reply to comment #5)
> A scaled down version of this feature should be built into NetBeans itself for
> purposes of allowing users to report
> performance issues against NetBeans.
This is already implemented in NB 6.7. See issue #153221.
Integrated into 'main-golden'
User: Tomas Hurka <email@example.com>
Log: issue #113276, CPU sampling implemented
Done for 7.1.