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.
Summary: | Stack-trace for memory leaks should be reversed | ||
---|---|---|---|
Product: | profiler | Reporter: | _ gtzabari <gtzabari> |
Component: | Base | Assignee: | issues@profiler <issues> |
Status: | NEW --- | ||
Severity: | blocker | ||
Priority: | P2 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
_ gtzabari
2005-05-20 03:36:44 UTC
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 |