[
https://issues.apache.org/jira/browse/FELIX-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall resolved FELIX-728.
-----------------------------------
Resolution: Fixed
Assignee: Richard S. Hall
This makes sense to me, clearly it was an oversight and the request variables
should have been nulled in the loop, but moving the declarations inside the
loop is also good. I have committed the patch. Please close if you are
satisfied. Thanks.
> Garbage Collection Corner Cases in PackageAdminImpl and StartLevelImpl
> ----------------------------------------------------------------------
>
> Key: FELIX-728
> URL: https://issues.apache.org/jira/browse/FELIX-728
> Project: Felix
> Issue Type: Improvement
> Components: Framework
> Affects Versions: felix-1.0.4, felix-1.2.0
> Reporter: Felix Meschberger
> Assignee: Richard S. Hall
> Attachments: FELIX-728.patch
>
>
> While tracking down memory issues in our OSGi based application, I stumbled
> upon two corner case issues in the StartLevelImpl and PackageAdminImpl
> classes, which both implement the Thread.run() method to execute their
> operations asynchronously. Each of these run methods have a local variable
> which is not reset after executing the operation:
> StartLevelImpl.run() has an "Object request". This is set to the start level
> request. For example to set the start level of a bundle, the request object
> is an array of two elements containing the bundle whose start level is to be
> set and the actual startlevel. After setting the start level the
> StartLevelImpl.run method keeps a string reference to the request object,
> most notably the Bundle. If now a bundle is installed, its startlevel is set
> and then the bundle is uninstalled, the actual bundle as well as its class
> loader and classes will only be unloaded when a new request is sent to the
> StartLevelImpl class. To fix this situation, I propose to move the definition
> of the request variable inside the loop. This way, the variable is dropped
> together with any string references.
> Similarly the PackageAdminImpl.run() method has a "Bundle[] bundles"
> variable, which is also not reset. The fix is the same as for the
> StartLevelImpl.run() method, in that the variable declaration is moved inside
> the loop.
> While I did not stumble upon the PackageAdminImpl issue, I encountered the
> StartLevelImpl one.
> Will attach a patch for review.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
