Summary: | Duplicate strings of VM path | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | John Arthorne <john.arthorne> | ||||||
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | frederic_fusier, panagiotis.korros | ||||||
Version: | 3.1 | Keywords: | performance | ||||||
Target Milestone: | 3.1 M7 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows 2000 | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
John Arthorne
2005-03-31 12:02:49 EST
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. |