On Sun, Jun 3, 2012 at 9:02 AM, <[email protected]> wrote:
> Even using a custom SM or java.lang.instrumentation it's pretty difficult > to answer question such as "who is allocating so much memory?". Christer > Larsson (MakeWave) and I demonstrated a resource management API at the > OSGi Community Event in Darmstadt last year, but this also relied on > modifying the JVM - I think it is pretty well impossible to develop a > performant solution otherwise. > Sorry, I didn't mean that those suggestions could lead to actual complete solutions. > You also have to ask yourself just what you mean when you say "a service > bundle eats too much memory". As has already been pointed out in this > thread, services can call other services and objects can be passed from > one service to another, so it is hard to say that a thread or an object > "belongs" to a particular bundle. Take the case of a component in bundle > A which receives messages on some interface and passes them on to all > services which have registered an interest. One such service component, > in bundle B, accepts and processes these messages but owing to a > programming error it retains a reference to all the messages so they > cannot be garbage-collected. So we have a memory leak, and if we ask the > question "which bundle allocated all this memory" the answer is "bundle > A". Yet bundle A is innocent of any crime, and moreover stopping bundle A > will not solve the problem (since B is holding references to the objects). > I completely agree. In those cases it's pretty impossible to articulate who is at fault. > If the JVM would support Isolates (JSR121), it might be possible to device > an efficient inter-isolate communications protocol to invoke Remote > Services on another Isolate ... > Again, I agree. (it's interesting since it seems that this is precisely the type of technology that forms one of the major underpinnings of Google's Dalvic VM: isolated "processes" using shared class/library-space) Though I think that if one were to attempt even a partial implementation, the answer's still remain that the current "closest" thing you have to work with are SM and instrumentation (and JVM customization). -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> <http://twitter.com/#!/rotty3000> | Senior Software Architect | *Liferay, Inc.* <http://www.liferay.com> <https://twitter.com/#!/liferay> --- 8-9 October 2012 |* Liferay **North America Symposium* | liferay.com/northamerica2012 <http://www.liferay.com/northamerica2012> 16-17 October 2012 |* Liferay **Europe Symposium* | liferay.com/europe2012<http://www.liferay.com/europe2012> 24-25 October 2012 |* Liferay **Spain Symposium* | liferay.com/spain2012<http://www.liferay.com/spain2012>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
