Community
Participate
Working Groups
I am testing an adopting product that has lots of bundles. I am trying to determine why it is using more memory than the same set of projects using Ganymede. One thing I have discovered, is that simply the presence of more bundles in your product, even if they are not activated, incur a reasonably high memory cost. Please see the attached snapshot. It shows Ganymede on the left and my product on the right. You can see that the osgi classes are holding onto much more memory. If these structures are not needed at runtime, they should be written to disk (and freed), so that simply the presence of lots of bundles should not incur these costs. And/or the structures themselves should be optimized to use memory more efficiently.
Created attachment 129209 [details] screenshot that shows memory differences
Could you precise the number of plug-ins running in each install? Also could you characterize the nature of the relationship between those plug-ins (do you think they have a denser set of connections with others than in the "ganymede" set)?
Here the bundles by State: Ganymede Active 136 Resolved 132 Starting 353 Adopting Product Active 210 Resolved 271 Starting 1226
(In reply to comment #3) BTW, I find the numbers a bit puzzling for the bundles that are in the Started state. As near as I can tell, these are the bundles that don't have start() methods, and don't have anything to do with whether they are starting or not. Is this correct?
We do flush as much data as possible from the SystemState after 5 minutes has passed with no access to the resolver state. In your testing you could reduce the amount of time we wait to unload the data by setting osgi.lazyStateUnloadingTime to a low number (e.g. 1000 for 1 second). If you bring up the produce and let it rest for couple of minutes do you see a reduction in memory of the SystemState? The UserState is not used by the runtime. This Object is likely a result of PDE's usage of the resolver APIs. (In reply to comment #4) > (In reply to comment #3) > > BTW, I find the numbers a bit puzzling for the bundles that are in the Started > state. As near as I can tell, these are the bundles that don't have start() > methods, and don't have anything to do with whether they are starting or not. > Is this correct? > Do you mean the bundles in the STARTING state? These are bundles that have a lazy start policy (Eclipse-LazyStart: true or Bundle-ActivationPolicy: lazy headers). This should not effect the amount of memory of the Framework. These bundles are simply waiting for the first class load before the framework lazily activates them.
Created attachment 129381 [details] another screenshot I added the -Dosgi.lazyStateUnloadingTime=5000 parameter, it had an effect but not as much as I was hoping for, and it didn't have any effect on some of the other big osgi classes. Am I setting this parameter correctly? This parameter wasn't mentioned in the help text, is this supported on 342?
Created attachment 129382 [details] lots of Object[1]'s In looking at the this large VersionHashMap it mostly has values of Object[1]. An Object[1] takes 24 bytes on a 32 bit JVM. If this could be replaced with simply an Object and only grown to an array when needed, there would be an opportunity to save some space. Every bit helps.
Created attachment 131470 [details] remove Object[1] arrays Here is an experimental patch that avoids Object[1] arrays. Memory analysis tool indicates ~10% memory gain in the UserState object PDE uses when targeting Eclipse SDK 3.5 build. It would be interesting to see if how much gain this gets you in the large product scenario.
Created attachment 131522 [details] BundleRepository patch We have a similar pattern in the BundleRepository. Doing a similar change to this class did not result in much improvement in memory heap. I suspect this is because the granularity is at the bundle level where the resolver is at the package level. The number of packages is general much greater than the number of bundles in a framework.
I released the patch to the resolver. Marking as fixed, although I'm sure you have higher expectations for improvement. Please open new bugs if you have additional data on where we are taking up too much memory and/or if you have other suggestions on how we can improve. Thanks.
