I am excluding weak and soft references, because they cannot be the root cause for keeping the WorkbenchWindow alive.Įxpanding the view a little bit, I get the following picture: Via the context menu, I select to display the shortest path to the GC roots. This looks okay, so the first one is suspicious. The second object is referenced by the Workbench via activeWorkbenchWindow. To decide which of the objects is good and which is bad, I open the incoming references. I choose the incoming references to see who is immediately referencing these WorkbenchWindow instances: So let’s open the histogram and filter (the first row) by that class:Įt voilà, we have 2 instances even though we already closed the second window. And we can assume some implementation knowledge: a workbench window is represented by the class WorkbenchWindow. In our case we can make it easy: we specifically test the “New Window” scenario so that’s what we are looking for. The difficult part is to find the leaking object. Those are needed for fast access to the data in the dump. The heap dump will be parsed and a number of index files is created next to the dump. Start the Memory Analyzer and select “Open Heap Dump…” from the File menu. Open the Heap Dump in the Memory Analyzer The second parameter p1 should be left at true as we are only interested in live objects.
Make sure you give it the file extension.
The first parameter p0 is the full path to the heap dump file. Then, select the operation dumpHeap from the MBean. Start /bin/jconsole.exe and select the running Eclipse IDE: Please note: you cannot use JConsole on JRE 5 VMs because the MBean does not provide the operation to write a heap dump. You can configure your JRE in the Eclipse Preferences: Java -> Installed JREs. On Windows, I find the easiest way is to use JRE 6 and JConsole.
Then I started the IDE, opened a new window via Window -> New Window and closed the window right away. I did use an Eclipse 3.4M6a milestone build and reproduced the leak by using a default launch configuration for the product. Looking at that reference path, we can decide which reference should be removed as it is accidentally keeping the leaking object alive.Įnough theory, let’s get started… Reproduce the Leak method parameters and local variables), the thread itself and classes loaded by the system class loader. GC roots are objects which are assumed to be reachable by the virtual machine: objects on the call stack of the current thread (e.g. To do this, we follow the reference chain from the object to the Garbage Collection (GC) roots. Once we got hold of the leaking object, we have to determine why it is still around. In our case this means that instances of WorkbenchWindow are not garbage collected even though the window is closed and the workbench window instance is not needed anymore. In Java programs, leaks are objects which are not used/needed anymore, but which are still reachable and therefore are not removed by the Garbage Collector. Ī memory leak is an unintentional memory usage.
In this blog, I will use the “New Window” leak to explain how to find memory leaks using the Memory Analyzer.
Open and close a couple new windows and the heap usage grows more. He started programming on an Apple IIe when he was eleven, his first programming language was 6502 assembler.īillys current interests are lightweight non invasive middleware, complex event processing systems and grid based OLTP frameworks.This is a classic memory leak: Select Window -> New Window in your Eclipse IDE and then close the new window right away. He wrote video games in C and assembler on the ZX Spectrum, Atari ST and Commodore Amiga as a teenager. He's also the lead persistence architect and runtime availability/scaling architect for the base application server.īefore IBM, Billy worked as an independant consultant at investment banks, telcos, publishing companies and travel reservation companies. Billy currently works on WebSphere XD and ObjectGrid. Billy lead the design of the WebSphere 6.0 non blocking IO framework (channel framework) and the WebSphere 6.0 high availability/clustering (HAManager). Billy was the lead on the WorkManager/ Scheduler APIs which were later standardized by IBM and BEA and are now the subject of JSR 236 and JSR 237. Billy is a Distinguished Engineer at IBM.