Summary: | memory optimization in JavaModelCache | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Noel Grandin <noelgrandin> |
Component: | Core | Assignee: | Jerome Lanneluc <jerome_lanneluc> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | minor | ||
Priority: | P3 | CC: | jerome_lanneluc |
Version: | 3.0 | ||
Target Milestone: | 3.1 M2 | ||
Hardware: | PC | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Noel Grandin
2004-04-06 11:08:54 EDT
Thanks for the input. No promise we will change this for 3.0 release, but definitely good info. We could also reduce the size of the cache... Note of that of the 4 Maps here, one is a subclass of OverflowingLRUCache, and the others are HashMaps. That means that only one of them will stabilize in size, the others will just keep growing... But I have noticed the 3.0 is considerably lighter ITO mem. usage than 2.x, so it's not like I'm terribly disappointed :-) Will consider post 3.0 Reopening Changed JavaModelCache to use separate LRUCaches for projects, roots, packages and openables. (Note using WeakHashMap would not work as a reference from the parent would always exist). *** Bug 65272 has been marked as a duplicate of this bug. *** Pity about the WeakHashMap. The reason I suggested that was that I was hoping to avoid the situation where the LRUCaches are sometimes too small and sometimes too big. Sometimes I run Eclipse on RAM-constrained boxes with about 100-200 files in a workspace, normally to write testing/scripting code. Other times I run on big boxes with projects that have ~7000 java files where I am quite happy to trade RAM for a snappier dev environment. Verified for 3.1 M2 with build I200409230010. |