Summary: | Memory Leak in install -> start -> stop -> uninistall cycle | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Equinox | Reporter: | John Wells <jwells> | ||||
Component: | Framework | Assignee: | Thomas Watson <tjwatson> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | jwells, lfeigen, tjwatson | ||||
Version: | 3.3.1 | Keywords: | greatbug | ||||
Target Milestone: | 3.4 M7 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
John Wells
2008-03-27 14:43:07 EDT
I found that the increased objects are almost all referenced from the class org.eclipse.osgi.internal.resolver.BundleDescriptionImpl$LazyData directly or indirectly.(See the attached snapshot of one LazyData instance) And I also found that during the reduplicate deployment/undeployment, files as below will be created continuously. In fact, after 100 times deployment/undeployment were done, such 1000 set files were newly created. ---------------------------------------------------------- {CE_Instance_Dir}/osgicfg/org.eclipse.osgi/.bundledata.xxx {CE_Instance_Dir}/osgicfg/org.eclipse.osgi/.lazy.xxx {CE_Instance_Dir}/osgicfg/org.eclipse.osgi/.state.xxx ---------------------------------------------------------- From the above info, I guess maybe equinox keeps the 'lazy data' both in memory and disk based on some algorithm. So, I am not sure but I guess that the 'memory-leak' is not a problem if the increased objects are still controlled by equinox as 'lazy data'. I also tried to add a '-Dosgi.noLazyStateLoading=true' option as CE vm arg to see whether the 'memory-leak' does not occur when unusing 'lazy load'. But this option did not go into effect and the 'lazy datas' in both memory and disk are still created. I think this is really a problem of Equinox. The reason is that class org.eclipse.osgi.internal.module.ResolverBundle maintains a arraylist named 'refs', and it only provides a addRef() method for adding member to this arraylist but a removeRef() method for removing member from the arraylist is not provided. In detail, if 'org.osgi.framework' is included in the 'Import-Package' list of the manifest.mf of a bundle, when this bundle is being resolved, the 'ResolverBundle' instance of this being deployed bundle will be added to 'refs' list in the 'ResolverBundle' instance of 'System Bundle'. But, when the deployed bundle is being unresolved, nothing will be removed from 'refs'. The attached file is a decompiled java file from the class org.eclipse.osgi.internal.module.ResolverBundle.class in org.osgi.eclipse.equinox_3.3.1.p1.jar we now using. You can find the init and add methods for 'refs' as below, but there is no remove method for 'refs' at all. ---------------------------------------------------- void initialize(boolean useSelectedExports) { if(getBundle().isSingleton()) <= the 'System Bundle' will satisfy this condition. refs = new ArrayList(); ... } void addRef(ResolverBundle ref) { if(refs != null && !refs.contains(ref)) refs.add(ref); } ----------------------------------------------------- Only for test purpose, I tried to use 'Import-Package: com.bea.core.workmanager' to replace the original 'Import-Package: org.osgi.framework' in the menifest.mf of the bundle which is repeatably deployed/undeployed during the test so that the 'refs.add(ref)' will not be invoked. And then, the 'memory-leak' disappeared. Thanks for the great analysis John (kudos with a greatbug)! I will investigate for M7. Created attachment 93892 [details] patch The resolver is in need of some serious love. I really hope GSOC project can help us move to a SAT4J solution (http://blog.bjhargrave.com/2008/03/equinox-and-google-summer-of-code.html) The ref stuff is only used to help in the selection of singleton bundles when we are attempting to resolve multiple versions of a singleton bundle at the same time. This patch clears the ref set after the singleton selection process and prevents the ref set from growing when a bundle is already resolved (and hence needs to ref counts for singleton selection). That last sentence should read ... and hence needs *no* ref counts for singleton selection Patch released for 3.4 M7. |