Community
Participate
Working Groups
Build: I20050331 I have my VM installed at the path D:\vm\sidecar\jre\bin\java I launch Eclipse in a profiler, and dump every instance of String to a file. I wrote a little program to process this dump file and count the number of copies of each string. The biggest culprits are listed below. Someone is holding onto a large number of VM paths - I don't yet know if this is JDT core, PDE, debug, or someone else. I will investigate a bit further, but I wanted to enter this while I had the data available. There is at least half a meg of wasted memory here that should be easy to fix when we find who's holding them. In this output, "count" is the number of equal copies of the string, "size" is an estimate of the memory use of those strings, in bytes, and "savings" is the memory reduction from sharing or interning all copies of that string. "D:" count: 3153 size: 151344 savings: 151296 "vm" count: 2953 size: 141744 savings: 141696 "lib" count: 2722 size: 136100 savings: 136050 "jre" count: 2653 size: 132650 savings: 132600 "sidecar" count: 1957 size: 113506 savings: 113448 "ext" count: 1118 size: 55900 savings: 55850 "sun141" count: 937 size: 52472 savings: 52416
Created attachment 19425 [details] Reference graph for VM path strings I've found the culprit, and it looks like JDT core is holding these strings. I checked the reference graph for a dozen or so copies of the string "sidecar", and all of the reference graphs looked like this one. If you could somehow share the entire Path objects for these JRE classpath entries, I believe it would save a significant amount of memory.
John, when did you take the memory snapshots ? This reference (through the 'persistedContainers' field) should go away as soon as the project is used.
The initial set of numbers I actually gathered a few days ago, and I can't recall the exact scenario. However, when I was tracking this down today, I did the following: - Open a workspace that contained platform-core projects - Deleted all projects - Created a simple Java project - Hit Ctrl+Shift+T and waited for indexing to complete - Generated heap snapshot Could it be that stale information from deleted projects is hanging around in this cache?
Yes this is stale information from deleted projects. We should remove it when the project is deleted or closed. Thanks for investigating this.
Created attachment 19432 [details] Eclipse preference file This is my eclipse preference file. I frequently export all my preferences when switching workspaces for testing. I might have imported these preferences into the workspace I was originally profiling. There are 2,750 occurrences of the string "sidecar" in my preference file, including classpathContainer values for projects I haven't had in my workspace for quite awhile. As another issue, if I export my preferences from my huge self-hosting workspace into a little test workspace, I really don't want these classpath container values to be clutering my preferences at all. I should mention that there is a new preference API, PreferenceModifyListener, that can be used to remove unwanted preferences on import. It might be appropriate for this case.
1. is this still an issue after cleanup of obsoleted container values ? 2. could it use the String cache of the Java model ? if so, pls instruct Frederic, and assign to him.
Changed DeltaProcessor#updateCurrentDeltaAndIndex(...) to cleanup the previous session containers for the project when it is deleted. Moving to Frederic for the export/import preferences problem.
Fixed and released in HEAD. Added JavaCorePreferenceModifyListener to remove container preferences on non-accessible project. To verify it works, just create a new workspace, import existing preferences, export them and verify that there's no container preferences in exported file... Currently, there's no test case added. I'll add one if time permit...
(In reply to comment #8) Verified this part for 3.1 M7 using build I20050509-2010 + jdt.core HEAD.
