Community
Participate
Working Groups
Build: 3.3 M6 IBM Java 5 VM. I performed a rename refactoring on a package in my workspace. I have a large workspace, but this particular package only had a handful of references, and contained only one class. The rename froze for 2-3 minutes. During this time I captured a stack trace (shown below). Eventually it failed with OutOfMemoryError. Maybe the location of the error is coincidence, but it is perhaps due to this cache becoming too large, or due to a loop in the linked list. I have never had an OutOfMemoryError on this machine with this VM before (machine has 2GB RAM). "ModalContext" (TID:0x1D878A00, sys_thread_t:0x0016D60C, state:CW, native ID:0x00000760) prio=6 at java/lang/OutOfMemoryError.<init>(OutOfMemoryError.java:50) at org/eclipse/jdt/internal/core/OverflowingLRUCache.elements(OverflowingLRUCache.java:120) at org/eclipse/jdt/internal/core/BufferManager.getOpenBuffers(BufferManager.java:106) at org/eclipse/jdt/internal/core/Openable.hasUnsavedChanges(Openable.java:346(Compiled Code)) at org/eclipse/jdt/internal/core/Openable.canBeRemovedFromCache(Openable.java:70) at org/eclipse/jdt/internal/core/ElementCache.close(ElementCache.java:46) at org/eclipse/jdt/internal/core/OverflowingLRUCache.privateRemoveEntry(OverflowingLRUCache.java:278(Compiled Code)) at org/eclipse/jdt/internal/core/OverflowingLRUCache.makeSpace(OverflowingLRUCache.java:180(Compiled Code)) at org/eclipse/jdt/internal/core/OverflowingLRUCache.put(OverflowingLRUCache.java:345(Compiled Code)) at org/eclipse/jdt/internal/core/JavaModelCache.putInfo(JavaModelCache.java:167(Compiled Code)) at org/eclipse/jdt/internal/core/JavaModelManager.putInfos(JavaModelManager.java:2729(Compiled Code)) at org/eclipse/jdt/internal/core/JavaElement.openWhenClosed(JavaElement.java:519(Compiled Code)) at org/eclipse/jdt/internal/core/JavaElement.getElementInfo(JavaElement.java:249(Compiled Code)) at org/eclipse/jdt/internal/core/JavaElement.getElementInfo(JavaElement.java:235(Compiled Code)) at org/eclipse/jdt/internal/core/JavaElement.getChildren(JavaElement.java:190(Compiled Code)) at org/eclipse/jdt/internal/core/search/matching/MatchLocator.locatePackageDeclarations(MatchLocator.java:1256) at org/eclipse/jdt/internal/core/search/matching/MatchLocator.locatePackageDeclarations(MatchLocator.java:1223) at org/eclipse/jdt/internal/core/search/JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:99) at org/eclipse/jdt/internal/core/search/BasicSearchEngine.findMatches(BasicSearchEngine.java:219) at org/eclipse/jdt/internal/core/search/BasicSearchEngine.search(BasicSearchEngine.java:504) at org/eclipse/jdt/core/search/SearchEngine.search(SearchEngine.java:549) at org/eclipse/jdt/internal/corext/refactoring/rename/RenamePackageProcessor$PackageRenamer.getNamesakePackages(RenamePackageProcessor.java:850) at org/eclipse/jdt/internal/corext/refactoring/rename/RenamePackageProcessor$PackageRenamer.getReferencesToTypesInNamesakes(RenamePackageProcessor.java:785) at org/eclipse/jdt/internal/corext/refactoring/rename/RenamePackageProcessor$PackageRenamer.doRename(RenamePackageProcessor.java:650) at org/eclipse/jdt/internal/corext/refactoring/rename/RenamePackageProcessor.doCheckFinalConditions(RenamePackageProcessor.java:409) at org/eclipse/jdt/internal/corext/refactoring/rename/JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:48) at org/eclipse/ltk/core/refactoring/participants/ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:174) at org/eclipse/ltk/core/refactoring/CheckConditionsOperation.run(CheckConditionsOperation.java:83) at org/eclipse/ltk/core/refactoring/CreateChangeOperation.run(CreateChangeOperation.java:118) at org/eclipse/ltk/core/refactoring/PerformChangeOperation.run(PerformChangeOperation.java:208) at org/eclipse/core/internal/resources/Workspace.run(Workspace.java:1798(Compiled Code)) at org/eclipse/ltk/internal/ui/refactoring/WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:87) at org/eclipse/jface/operation/ModalContext$ModalContextThread.run(ModalContext.java:113)
How much memory on VM command line ? (-Xmx)
Jerome, could we imagine getting information from Java Model (getChildren()) without populating it in this peculiar case?
We could indeed use NameLookup#findPackageFragments(String, boolean) instead.
No VM arguments. I have never found a need for them on IBM VMs.
Created attachment 64600 [details] Proposed patch
FSWST#testPackageDeclarations() performance test gives following results: Patch: 4.8ms (+/- 2,3ms) HEAD: 2062.4ms (+/-13,3ms) As with the patch time is under 100ms, I iterated it 20 times and get folllowing results: Patch x 20: 67.2ms (+/- 2,3ms) This makes an improvement of 99.8% :-))
Jerome, can you have a look on this patch please? Thanks
Created attachment 64696 [details] New proposed patch Better patch as the indexOf on name is outside the loop in NameLookup.findPackageFragments(...) method. Also, take into account patternMatch parameter even if partialMatch is false which was not the case in previous patch. Also added javadoc comment on this method.
Patch looks good (watch out the testONLY_ renaming :-) )
Patch released for 3.3 M7 in HEAD stream (without the ONLY_ in test name). Consider this problem fixed as we do no longer populate the Java Model. John, please give it a try with today's integration build and let us know if it's OK for you, thanks
Search package declaration shows a gain between 96.7% and 100% => consider as verified for 3.3 M7 using perf results of I20070424-0930
