Community
Participate
Working Groups
I20040812 The maximum size of the Java model caches is currently static. User should be able to dynamicaly update it so that he/she can work with larger/smaller workspaces.
Ideally, it should scale without me explicitly setting it. I can think of 2 strategies (a) memory sensitive. Jerome has indicated that using WeakHashMap won't work (not sure why). Also, my own experiences with WeakHashMap suggest that the VM is not very smart about GC'ing weakly linked stuff. Mind you, that was with JDK1.3. Things might have improved since then. (b) Scale it based on the number of java files in the currently opened workspace, with perhaps some kind of limit based on the currently configurated memory available to the VM. Something like int lruSize = Math.min(100, Math.min (noOfFiles/3,maxMemMegabytesConfigured/128*1000)). where the numbers I've inserted are a complete guess, and the additional min() call provides a lower bound for newly created workspaces.
Yes automaticaly detecting the cache size would be ideal. But a) the WeakHashMap behavior is weakly (<g>) specified (no guaranty that elements in the map will be garbagged collected in the near future) so we cannot rely on this b) this would mean traversing the whole workspace tree which can be costly I still think that having this limit as an option would be better.
*** Bug 75946 has been marked as a duplicate of this bug. ***
If I wanted to hardcode in a larger cache size, where would I need to edit?
That would be org.eclipse.jdt.internal.core.JavaModelCache#CACHE_RATIO.
Great, thanks! Is this only used in that class? i.e. can I get away with just compiling org.eclipse.jdt.core (public static final var, so compile time resolution)?
Yes this static field is used in this class only. It could be private.
Alternatively, we could investigate a different caching policy: never close indidividual roots, but rely on project getting closed at once. Similar to not closing packages, but rather roots as wholes. This may require to transfer some information from project element infos to per-project infos.
Just an FYI/confirmation - I doubled my CACHE_RATIO to 40 and my problems from bug 75946 went away.
Thanks for confirming this was the problem Matthew. Changed the JavaModelCache to increase its maximum size so that the children of an element always fit in the cache. It resets its limit to the default size when the element is closed. See JavaModelCache#ensureSpaceLimit(Map) and resetSpaceLimit(IJavaElement)
Verified for 3.1 M4 using build I200412140800. Please not that constant is now called BASE_VALUE in JavaModelCache.
This is still a source of major slowdown for me with a very large project in eclipse 3.1M4. If I edit JavaModelCache and double BASE_VALUE to 40, the slowdown goes away, so I suspect that the dynamic cache size adjustment is not taking place.
Matthew, could you please enable the Java model tracing as follows: 1. Create a .options file with the following content: # Turn on debug tracing for org.eclipse.jdt.core plugin org.eclipse.jdt.core/debug=true # Reports Java model elements opening/closing org.eclipse.jdt.core/debug/javamodel=false 2. Start Eclipse with -debug <path to the .options file> -vm <path to jre>\bin\java.exe 3. Ensure that the DOS console that is opened has a buffer size set to 9999 4. Copy/paste the trace in a .txt file and attach it to this bug report
Of course in comment #13 I meant: org.eclipse.jdt.core/debug/javamodel=true
Please reopen when you have the trace.
Here you go - Sorry it took so long, been busy at work and its time consuming for for me to retrace as I had to get/install an unmodified version of eclipse without my edit of JavaModelCache. I also added the following line to .options as that was neccessary for bug 75946 : org.eclipse.jdt.core/debug/resolution=true I opened eclipse, ctrl-tabbed between two different source windows, Select all (ctrl-a), Copy (ctrl-c), left click, and it usually takes about 10 secs before eclipse clears the selection. Second time in the same file is quick, but when I switch to another source file the slowdown reoccurs. The slowdown goes away when I double JavaModelCache.BASE_VALUE to 40 (which I need to do to resume real work =)
Created attachment 18104 [details] Log of slowdown
Won't let me reopen the bug, so I'll let you do it ;) Also, testing this with eclipse I20050218-1200 (M5 hopeful)
The JavaModel cache is now able to resize dynamically, and this was changed a while ago (2-3 months). Are you still observing the issue in M5 ?
Yes, still observing the problem in M5 The dynamic resize doesn't seem to work - or at least does not seem to be effective. If I edit the size of the JavaModel cache manually, the problem goes away, but hacking source code is not a good workaround for most people =)
reopening
One more observation - the method I use for reproducing the slowdown as described above only works if the two sourcefiles I switch between belong to different source folders in the same project.
Created attachment 18237 [details] Patch to apply on org.elipse.jdt.core v_538 Thanks for your efforts in helping tracking this down. I was able to reproduce by creating a Java project with 300 source folders. The problem is not really with the default size of the Java model cache, but with the fact that the root cache of the project is cleared too often. I also added another optimization when querying the kind of a root to avoid populating the cache. Could you please try the attached patch and let me know if this fixes your problem ?
Applied the patch, but it did not help.
Created attachment 18239 [details] Trace of slowdown after applying patch Ran through the same scenario I used for the previous trace, but did it using a patched org.eclipse.jdt.core v_538 on 3.1M5a
My test case was too simple. With cus refering to each other, I see the problem too. I'm investigating.
Created attachment 18249 [details] Patch to apply on org.elipse.jdt.core v_538 I think I have it now. Could you please try with this new patch ?
Excellent! That seemed to do the trick. Thanks!
Thanks for confirming this works. Released patch into HEAD. Added regression test OverflowingCacheTests#testBigNumberOfRoots()
Verified in I20050330-0500
