Marcelo Fukushima wrote: > there's a jvm argument that makes it dump the heap on OOME. i use that > as a starting point and either jhat or visualvm to analyze it... > the process I've provided it quick and easy. Generational count tells you exactly which object is leaking, heap walker tells you exactly how it is connected, the allocation stack trace tells where where to start your trace from creation to linkage in the code. Generally I can solve memory leaks in 30 minutes or less using this technique.
Regards, Kirk > On 9/16/09, kirk <[email protected]> wrote: > >> kittu wrote: >> >>> Hi >>> >>> I facing the problem of out of memory and fatal shutdown of the >>> device, in the logs i not able to find any clue regards memory >>> increament continuosly. the device is down after few days due to >>> continuous memory usage increment >256MB (actually 60 -90MB >>> acceptable). >>> >>> is any way to debug this scenario.? if so how ? >>> >>> >> netbeans profiler. >> >> 1) find the object with the highest generational count using the memory >> profiler >> 2) dump heap, find and instance of that object and use heap walker to >> find the reference path back to the GC root >> 3) use the reference path to understand what is holding onto the leaking >> object >> 4) use stack allocation at object creation time to know where to look in >> the application for the object. >> >> >> Regards, >> Kirk >> >> >> > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
