Community
Participate
Working Groups
20050427 platform-ui module and jdt ui loaded Java perspective open (default views) Editor on java.lang.Object open Push F4 on Object I tried to see what was going on using optimize it but it wasn't possible without an OutOfMemoryException. However using the heap monitor my heap jumped from 22M to 412M. After a garbage collect it settled back down to 95M
Looking at the objects generated by opening the hierarchy on Control we get 16035 MethodBindings 18444 Hashmap entires 11841 ArrayLists 8049 MethodInfos
Created attachment 20454 [details] Heap snapshot (no GC)
Philippe, these objects are all created in JDT/Core land. My be we have to do the same trick as in search and put GC in between. I remember that we did this trick since the GC wasn't run also there were objects to collect. Martin, do you konw how big the memory consumption is in UI
The problem is in IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(String [], HashSet, IProgressMonitor) allPotentialSubTypes is 9743 elements in my case & cannot deal with the numerous calls to buildForProject
Kent, can you please explain how allPotentialSubTypes cannot deal with the numerous calls to buildForProject ?
I didn't mean to say the collection could not deal with it... but the code in IndexBasedHierarchyBuilder.buildFromPotentialSubtypes is causing the OofM exception because of its large size.
With 3.0.2 in my normal JDT Core workspace, I can open the hierarchy of Object in 17 seconds & my memory usage peaked at 178Mb up from 79. With 3.1 M6 in my normal JDT Core workspace, I can open the hierarchy of Object in 35 seconds & my memory usage peaked at 180Mb up from 77. So we got twice as slow but did not increase our memory consumption. BUT with last night's build in my normal JDT Core workspace, I fail to open the hierarchy of Object with an OutOfMemory exception at 45 seconds & my memory usage peaked at 320Mb up from 68.
At the ~30 second this is the stack trace: "ModalContext" prio=7 tid=0x03428620 nid=0xf34 runnable [3caf000..3cafd8c] at o.e.c.i.localstore.FileSystemResourceManager.locationFor (FileSystemResourceManager.java:423) at o.e.c.i.resources.Resource.getLocation(Resource.java:877) at o.e.j.i.c.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:574) at o.e.j.i.c.hierarchy.IndexBasedHierarchyBuilder.buildForProject(:200) at o.e.j.i.c.hierarchy.IndexBasedHierarchyBuilder.buildFromPotentialSubtypes at o.e.j.i.c.hierarchy.IndexBasedHierarchyBuilder.build at o.e.j.i.c.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:320) at o.e.j.i.c.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1244) - locked <0x125c69f8> (a o.e.j.i.c.hierarchy.TypeHierarchy) at o.e.j.i.c.CreateTypeHierarchyOperation.executeOperation(:90) at o.e.j.i.c.JavaModelOperation.run(JavaModelOperation.java:718) at o.e.j.i.c.JavaModelOperation.runOperation(JavaModelOperation.java:777) at o.e.j.i.c.BinaryType.newTypeHierarchy(BinaryType.java:817) at o.e.j.i.c.BinaryType.newTypeHierarchy(BinaryType.java:836) at o.e.j.i.c.BinaryType.newTypeHierarchy(BinaryType.java:806) at o.e.j.i.ui.typehierarchy.TypeHierarchyLifeCycle.createTypeHierarchy(:118) at o.e.j.i.ui.typehierarchy.TypeHierarchyLifeCycle.doHierarchyRefresh(:157) - locked <0x125c6ad0> (a o.e.j.i.ui.typehierarchy.TypeHierarchyLifeCycle) at o.e.j.i.ui.typehierarchy.TypeHierarchyLifeCycle$1.run(98) at o.e.jface.operation.ModalContext$ModalContextThread.run(113) "main" prio=7 tid=0x00033e80 nid=0xc70 runnable [7e000..7fc3c] at o.e.swt.internal.win32.OS.WaitMessage(Native Method) at o.e.swt.widgets.Display.sleep(Display.java:3206) at o.e.jface.operation.ModalContext$ModalContextThread.block(:154) at o.e.jface.operation.ModalContext.run(ModalContext.java:303) at o.e.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:624) at o.e.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:69) at o.e.jface.window.ApplicationWindow.run(ApplicationWindow.java:621) at o.e.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2139) at o.e.j.i.ui.th.TypeHierarchyLifeCycle.ensureRefreshedTypeHierarchy at o.e.j.i.ui.th.TypeHierarchyViewPart.updateInput at o.e.j.i.ui.th.TypeHierarchyViewPart.setInputElement at o.e.j.i.ui.util.OpenTypeHierarchyUtil.openInPerspective at o.e.j.i.ui.util.OpenTypeHierarchyUtil.open at o.e.jdt.ui.actions.OpenTypeHierarchyAction.run at o.e.jdt.ui.actions.OpenTypeHierarchyAction.run at o.e.jdt.ui.actions.SelectionDispatchAction.dispatchRun at o.e.jdt.ui.actions.SelectionDispatchAction.run at o.e.jface.action.Action.runWithEvent(Action.java:996) .... at o.e.core.launcher.Main.main(Main.java:948)
Due to a change in the container path format, we were creating a ClassFileReader for each potential subtype and holding all ClassFileReaders in memory. Changed IndexBasedHierarchyBuilder to use the forward slash representation of the root path.
Note that opening the hierarchy on Object in a full R3.0 source workspace, it takes 43s in 3.0.2, and it takes 49s with HEAD.
Verified for 3.1 M7 using build I20050509-2010 + jdt.core HEAD. (with only org.eclipse.jdt.core project loaded in workspace, it takes 50s with 3.1 M6 and 20s with 3.1 M7...)
