Thank you guys for your valuable ideas! I am much clear on this topic now.
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 2012年6月4日 0:00 To: [email protected] Subject: osgi-dev Digest, Vol 68, Issue 2 Send osgi-dev mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://mail.osgi.org/mailman/listinfo/osgi-dev or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of osgi-dev digest..." Today's Topics: 1. Re: What is OSGi bundle profiling going on? ([email protected]) ---------------------------------------------------------------------- Message: 1 Date: Sun, 3 Jun 2012 14:02:34 +0100 (BST) From: [email protected] Subject: Re: [osgi-dev] What is OSGi bundle profiling going on? To: "OSGi Developer Mail List" <[email protected]> Message-ID: <[email protected]> Content-Type: text/plain;charset=iso-8859-1 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. 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). 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 ... Chris Gray >> My team is developing a service platform on OSGi platform. >> One big concern of my boss is bundle resource monitoring/profiling on >> service bundles. >> That is, if a service bundle eats too much memory or CPU, can OSGi >> runtime >> detect this event and take some action? >> >> > > I think the only way to do it in stock jvm & OSGi is to take advantage of > java security API which gives you the possibility collect bundle metrics > as > they call through the security API. This gives you access to all > classloading, thread management, resource access, etc. > > You will have to write a custom SecurityManager which tracks bundle > metrics, and also supports OSGi enhanced java security (perhaps extending > an existing implementation like > org.eclipse.osgi.internal.permadmin.EquinoxSecurityManager). > > It will not be trivial, but it is as close as you can get in stock java > APIs (that or instrumenting the JVM, java.lang.instrument). > > Furthermore, expect a considerable performance degradation, even without > customization, when using java security because it's quite intense. > > -- > *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 ------------------------------ _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev End of osgi-dev Digest, Vol 68, Issue 2 *************************************** _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
