Summary: | Opening the Type Hierarchy of Object uses 400M of heap | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Tod Creasey <Tod_Creasey> | ||||
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | critical | ||||||
Priority: | P3 | CC: | kent_johnson, martinae, philippe_mulet | ||||
Version: | 3.1 | Keywords: | performance | ||||
Target Milestone: | 3.1 M7 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Bug Depends on: | |||||||
Bug Blocks: | 61369 | ||||||
Attachments: |
|
Description
Tod Creasey
2005-04-28 09:06:55 EDT
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...) |