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.
Add the ability to not take allocation stack traces at all to lower the overhead. Most other profilers by default do not do this and focus on reporting correct number of live classes or a heap dump. Per discussion with NB performance team and observation from other profilers, the allocation stack traces are the least important thing when it comes to memory leak debugging. Most profilers do: - only live object (i.e. do not provide "only allocations" mode), reporting all of them (not 1/n th) - heap dump on request, by default without allocation stack traces
Well, there are other users that work with applications other than NB, and for them stack traces seem to be quite important at times, as we've just learned today. I also know of some of them who use the "allocation only" memory profiling mode to find out allocation hot spots with minimum possible overhead. However, to give the user an option to not take stack traces is perfectly ok. It can be easily done without adding any new options, by just setting (under the covers) the value in "Stack sampling: limit to" to 0 (or a negative value equal by modulus to current non- zero depth, so that if the user switches back to taking stack samples, the old positive value can be easily restored). To modify the engine to not take stack traces in that case is trivial.
I believe we are done with this now.
Verification of old issues.
Closing old issues.
Reverting to the original Target Milestone value changed by mistake. Sorry for inconvenience.