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.
Currently when using the profiler to look for memory leaks the "class name" column displays a list of types of objects that are allocated and if you "Show Allocations Stack Traces" on it it displays a tree where the parent is the class constructor of the allocated object and the children lead up to the top of the call-stack leading to that constructor call. This is very unintuitive. When I'm looking for memory leaks, I want to be able to drill from the top-down, not from the bottom-up. I want to look at the call-stack from the top-level methods, then find out which of their children methods allocate the most amount of memory. I don't care what kind of object is being leaked as much as which method allocated those objects in the first place. Right now I find the profiler almost useless for memory leak detection. It takes way too long to get at the data I'm looking for. What do you think?
Let me see if I understand correctly what you mean. There are two possible approaches: 1. once you determine which objects are leaking, you would like to see their allocation call stacks in a forward way 2. you would like to have a view similar to CPU Call Tree, displaying information about amount of memory allocated in each method (instead of CPU time) If 1. is what you mean, could you explai a bit more why the reverse graph is less useful?
I don't remember how the CPU usage looked like so I will try explaining without it. Think about it this way: most programs are going to be leaking char[] or byte[] simply because these are the most widely used low-level variable types so listing them as the top leaks is kinda useless. It is very rare (in my mind) that telling me what *kind* of variable is leaking is going to help me actually fix the leak. What is useful for me is to know *where* it is being leaked from. Usually you end up finding defective code-blocks which need fixing. byte[] might be allocated perfectly fine in one block but wrong in another which is why listing the allocation type is irrelevant. I hope this clarifies my view. Anyway, if you take a look at OptimizeIT's memory view they list it this way.
Milestone cleanup: future->next