You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@felix.apache.org by Nima Kaviani <ni...@gmail.com> on 2010/02/19 08:10:37 UTC

OSGi Bundle Profiling

Hi all,

I wonder if anybody knows of any profiling library / API that would allow me
to monitor the CPU and memory usages at a bundle level of granularity?

I have already looked into JProfiler, but there are two problems with
JProfiler. It is not a free tool, and also its profiling happens the level
of objects and packages (the second issue could have been resolved if I
could play around with the source code of course). I also found this thesis
(http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf)  which takes a rather
intrusive approach in modifying the internals of an osgi framework in order
to support resource monitoring and profiling. Any help along this line is
very much appreciated.

thanks,
-Nima

-- 
http://nima.magic.ubc.ca

Re: OSGi Bundle Profiling

Posted by Pierre De Rop <pi...@gmail.com>.

Hi Nima,

I uses VisualVM (https://visualvm.dev.java.net/) with the following jvm
options:

-Dcom.sun.management.jmxremote.port=3333 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Djava.rmi.server.hostname=HOST \

(replace "HOST" by your host name).

You must also set the following configuration in your felix
config.properties:

 org.osgi.framework.bootdelegation=org.netbeans.lib.profiler.*


There is an option in the GUI which allows to filter on java package names,
so you should be able to easily profile your bundle.
(warning: the cpu profiler does not work remotely)

Hope this helps;
/pierre



On Fri, Feb 19, 2010 at 8:10 AM, Nima Kaviani <ni...@gmail.com>wrote:

> Hi all,
>
> I wonder if anybody knows of any profiling library / API that would allow
> me
> to monitor the CPU and memory usages at a bundle level of granularity?
>
> I have already looked into JProfiler, but there are two problems with
> JProfiler. It is not a free tool, and also its profiling happens the level
> of objects and packages (the second issue could have been resolved if I
> could play around with the source code of course). I also found this thesis
> (http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf)  which takes a
> rather
> intrusive approach in modifying the internals of an osgi framework in order
> to support resource monitoring and profiling. Any help along this line is
> very much appreciated.
>
> thanks,
> -Nima
>
> --
> http://nima.magic.ubc.ca
>

Re: OSGi Bundle Profiling

Posted by teemu kanstren <tk...@gmail.com>.

Hello Nima,

 If you intend to work on this, I am interest to collaborate with whatever I
can help. I agree the optimal case would be to have a completely independent
module. However, I fear implementing it in an effective way would be
difficult. That should not stop us from trying of course. Do you have some
ideas you wish to share?

 I would personally be interested in monitoring different aspects of the
OSGI bundles/services, starting with all their interactions and
bundle/service resource consumptions. Maybe you already know of some way to
monitor interactions between different services (invocations to any service)
without proxies? For the resource consumption one major issue for me is that
I don't know of a generic way to get resource consumption information
breakdown information from a JVM, and if I could, then I would not know how
to map each resource used to bundles/services without something like the
threadpool solution.

Teemu

2010/3/2 Nima Kaviani <ni...@gmail.com>

> Hello all,
>
> I was holding on the reply for a bit to get some more input on this topic.
>
> Thanks Marcel for the link to I-JVM. There were interesting ideas discussed
> in the paper, however it still seems to me that they somehow impose
> constraints on using threads for Bundles and the OSGi container (Page 5)
> which again emphasizes the need to monitor or isolate bundle behaviors
> using
> thread pools. On a separate note, I am mainly looking for an approach that
> makes as minimal change as possible to the existing JVM or OSGi
> architecture. Unless there is going to be a standard for defining a clear
> cut border between bundles at the level of JVM or OSGi container, making
> assumptions on how a JVM or OSGi container should work to support
> monitoring
> does not work in my case. Yet, as you also said, some of their ideas might
> be applicable to bundles without having to modify the internals of a JVM or
> OSGi container.
>
> Teemu, I would highly appreciate the help from anyone who would like to
> collaborate or brainstorm on developing a monitoring module for OSGi
> bundles. I think it probably is better to see how close we can get to a
> proper monitoring module without having to modify the internal of an OSGi
> container to extend it with proxy bundles or using thread pools.
>
> -Nima
>
> On Sat, Feb 27, 2010 at 10:01 AM, teemu kanstren <tkanstren@gmail.com
> >wrote:
>
> > Hello Nima,
> >
> >  It would be interesting and nice to have some service available at the
> > container level to monitor the resources of a bundle as well as its
> > interactions more generally. I know I would like to use some stuff like
> > this.
> >
> > But I have to agree it is hard to do without the ThreadPool approach. You
> > need some means to associate the executed code and the used resources to
> > the
> > correct bundle. The ThreadPool seems to give you this. Do you have some
> > idea
> > of the overhead it has as this seems to concern you? It does not sound
> like
> > it would be a big overhead.
> >
> > It also seems like a lot of work to implement all the required
> > functionality
> > for effective monitoring, such as proxy creations, modifications of the
> > container for the ThreadPool, instrumenting all object creation, etc. So
> it
> > would be nice to have this stuff implemented as services that could be
> used
> > as is, without need to redo many times. But I have no idea how to try to
> > get
> > this into some OSGI spec. Maybe if you implement something, you could
> > provide it for the Felix implementation as a first step? Given some time
> > constraints, maybe you could also get some contributions from others.. :)
> >
> > Teemu
> >
> >
> > 2010/2/27 Nima Kaviani <ni...@gmail.com>
> >
> > > Hello all,
> > >
> > > @Pierre, thanks for pointing out JVisualVM. It looks like an excellent
> > > tool,
> > > but it doesn't expose any API that I can use in order to
> programmatically
> > > monitor the behavior of OSGi bundles or do some further analysis on the
> > > collected data.
> > >
> > > Since Cliff and Ali also showed some interest in this topic, I thought
> I
> > > would discuss the results of my search for the past couple of days here
> > to
> > > also benefit from your bright minds and come up with some solutions on
> > how
> > > bundle profiling could be implemented for a SPEC 4.2 compliant OSGi
> > > framework.
> > >
> > > I examined some of the most up to date profiling tools, namely,
> > JProfiler,
> > > JProbe, JVisualVM, JPI, JRockit Mission Control, and YourKit. The first
> > > three are proprietary and do not expose any API. JRockit Mission
> Control
> > is
> > > free and has some sort of an API that could be used for profiling, but
> it
> > > only works with JRMC and when I ran felix against it, it drastically
> > slowed
> > > down the performance of my application. JPI profiling results would
> only
> > > give me information on org.osgi.framework classes and nothing else! Not
> > > sure
> > > if this is because of having several class loaders for different
> bundles
> > or
> > > whether there is something else confusing JPI. YourKit is apparently
> the
> > > only one which comes with an API but it does not provide monitoring at
> a
> > > level as fine-grained as JVisualVM (as Pierre said one can monitor
> > > processes
> > > in JVisualVM at the level of methods, classes, or packages, making
> > possibly
> > > to cherry pick the classes or packages and associate them with
> bundles).
> > >
> > > I think what I am going to do is to write a bundle that would
> incorporate
> > > YourKit's API so that I can examine how closely I can resemble the
> > behavior
> > > of a target bundle by monitoring its behavior as a matter of combining
> > > collected information from YourKit and information received from the
> > > BundleContext. So it would be like, inspecting the internal of a bundle
> > by
> > > reflection and then matching them against the results of thread stack
> > trace
> > > from the profiler. Do you guys have any better suggestion?
> > >
> > > @Cliff, I agree that thread pooling per bundle is an expensive task
> > > (specially with what YourKit offers, I have to inspect the thread stack
> > > trace in order to pool out the information that I require), but I
> > couldn't
> > > think of any other way that would allow me to establish the
> associations
> > > between a process and its source bundle. so, I couldn't think of any
> > > alternative to what was suggested in the masters thesis I referenced
> > > earlier
> > > in this thread. Do you have a better idea? I mean, even if there is
> going
> > > to
> > > be a Profiling RFC for the next OSGi Spec, what could it be
> (considering
> > > what JMX offers)? I am asking cause I might be able to somehow try it
> in
> > my
> > > code and get some hints about how it may work.
> > >
> > > thanks guys and sorry for the long email. your thoughts and suggestions
> > on
> > > this matter are very much appreciated of course.
> > >
> > > -Nima
> > >
> > >
> > > On Fri, Feb 19, 2010 at 8:48 AM, Ali Naddaf <al...@gmail.com>
> > wrote:
> > >
> > > > I am also interested in knowing what one can do there. I have read
> that
> > > J9
> > > > has some extensions that enables a granular control of resources
> > (memory,
> > > > CPU) at the bundle level and ProSyst folks have some management tools
> > > around
> > > > that but that is the only JRE that I have heard whcih has that kind
> of
> > > > capability, and of course that is not a universal feature of JREs so
> > > won't
> > > > help most people.
> > > >
> > > >
> > > > On 2/19/2010 10:40 AM, Clifford H. James wrote:
> > > >
> > > >> I had wondered the same thing and at the time of my search all I
> found
> > > was
> > > >> that thesis project that you mentioned below.  Let me know if you
> find
> > > >> anything because this is an area that I think needs some attention
> > > (perhaps
> > > >> from the OSGi Alliance people in an upcoming spec?) but I'm not sure
> > if
> > > the
> > > >> "ThreadPool per bundle" that the author took doesn't create more
> > > troubles
> > > >> than it's worth -- it certainly isn't an unintrusive way to monitor
> > > bundle
> > > >> resource consumption.
> > > >>
> > > >> ~Cliff
> > > >>
> > > >> Nima Kaviani wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> I wonder if anybody knows of any profiling library / API that would
> > > allow
> > > >>> me
> > > >>> to monitor the CPU and memory usages at a bundle level of
> > granularity?
> > > >>>
> > > >>> I have already looked into JProfiler, but there are two problems
> with
> > > >>> JProfiler. It is not a free tool, and also its profiling happens
> the
> > > >>> level
> > > >>> of objects and packages (the second issue could have been resolved
> if
> > I
> > > >>> could play around with the source code of course). I also found
> this
> > > >>> thesis
> > > >>> (http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf)  which
> takes
> > a
> > > >>> rather
> > > >>> intrusive approach in modifying the internals of an osgi framework
> in
> > > >>> order
> > > >>> to support resource monitoring and profiling. Any help along this
> > line
> > > is
> > > >>> very much appreciated.
> > > >>>
> > > >>> thanks,
> > > >>> -Nima
> > > >>>
> > > >>>
> > > >>
> > > >>
> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > >> For additional commands, e-mail: users-help@felix.apache.org
> > > >>
> > > >>
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > For additional commands, e-mail: users-help@felix.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > http://nima.magic.ubc.ca
> > >
> >
>
>
>
> --
> http://nima.magic.ubc.ca
>

Re: OSGi Bundle Profiling

Posted by Nima Kaviani <ni...@gmail.com>.

Hello all,

I was holding on the reply for a bit to get some more input on this topic.

Thanks Marcel for the link to I-JVM. There were interesting ideas discussed
in the paper, however it still seems to me that they somehow impose
constraints on using threads for Bundles and the OSGi container (Page 5)
which again emphasizes the need to monitor or isolate bundle behaviors using
thread pools. On a separate note, I am mainly looking for an approach that
makes as minimal change as possible to the existing JVM or OSGi
architecture. Unless there is going to be a standard for defining a clear
cut border between bundles at the level of JVM or OSGi container, making
assumptions on how a JVM or OSGi container should work to support monitoring
does not work in my case. Yet, as you also said, some of their ideas might
be applicable to bundles without having to modify the internals of a JVM or
OSGi container.

Teemu, I would highly appreciate the help from anyone who would like to
collaborate or brainstorm on developing a monitoring module for OSGi
bundles. I think it probably is better to see how close we can get to a
proper monitoring module without having to modify the internal of an OSGi
container to extend it with proxy bundles or using thread pools.

-Nima

On Sat, Feb 27, 2010 at 10:01 AM, teemu kanstren <tk...@gmail.com>wrote:

> Hello Nima,
>
>  It would be interesting and nice to have some service available at the
> container level to monitor the resources of a bundle as well as its
> interactions more generally. I know I would like to use some stuff like
> this.
>
> But I have to agree it is hard to do without the ThreadPool approach. You
> need some means to associate the executed code and the used resources to
> the
> correct bundle. The ThreadPool seems to give you this. Do you have some
> idea
> of the overhead it has as this seems to concern you? It does not sound like
> it would be a big overhead.
>
> It also seems like a lot of work to implement all the required
> functionality
> for effective monitoring, such as proxy creations, modifications of the
> container for the ThreadPool, instrumenting all object creation, etc. So it
> would be nice to have this stuff implemented as services that could be used
> as is, without need to redo many times. But I have no idea how to try to
> get
> this into some OSGI spec. Maybe if you implement something, you could
> provide it for the Felix implementation as a first step? Given some time
> constraints, maybe you could also get some contributions from others.. :)
>
> Teemu
>
>
> 2010/2/27 Nima Kaviani <ni...@gmail.com>
>
> > Hello all,
> >
> > @Pierre, thanks for pointing out JVisualVM. It looks like an excellent
> > tool,
> > but it doesn't expose any API that I can use in order to programmatically
> > monitor the behavior of OSGi bundles or do some further analysis on the
> > collected data.
> >
> > Since Cliff and Ali also showed some interest in this topic, I thought I
> > would discuss the results of my search for the past couple of days here
> to
> > also benefit from your bright minds and come up with some solutions on
> how
> > bundle profiling could be implemented for a SPEC 4.2 compliant OSGi
> > framework.
> >
> > I examined some of the most up to date profiling tools, namely,
> JProfiler,
> > JProbe, JVisualVM, JPI, JRockit Mission Control, and YourKit. The first
> > three are proprietary and do not expose any API. JRockit Mission Control
> is
> > free and has some sort of an API that could be used for profiling, but it
> > only works with JRMC and when I ran felix against it, it drastically
> slowed
> > down the performance of my application. JPI profiling results would only
> > give me information on org.osgi.framework classes and nothing else! Not
> > sure
> > if this is because of having several class loaders for different bundles
> or
> > whether there is something else confusing JPI. YourKit is apparently the
> > only one which comes with an API but it does not provide monitoring at a
> > level as fine-grained as JVisualVM (as Pierre said one can monitor
> > processes
> > in JVisualVM at the level of methods, classes, or packages, making
> possibly
> > to cherry pick the classes or packages and associate them with bundles).
> >
> > I think what I am going to do is to write a bundle that would incorporate
> > YourKit's API so that I can examine how closely I can resemble the
> behavior
> > of a target bundle by monitoring its behavior as a matter of combining
> > collected information from YourKit and information received from the
> > BundleContext. So it would be like, inspecting the internal of a bundle
> by
> > reflection and then matching them against the results of thread stack
> trace
> > from the profiler. Do you guys have any better suggestion?
> >
> > @Cliff, I agree that thread pooling per bundle is an expensive task
> > (specially with what YourKit offers, I have to inspect the thread stack
> > trace in order to pool out the information that I require), but I
> couldn't
> > think of any other way that would allow me to establish the associations
> > between a process and its source bundle. so, I couldn't think of any
> > alternative to what was suggested in the masters thesis I referenced
> > earlier
> > in this thread. Do you have a better idea? I mean, even if there is going
> > to
> > be a Profiling RFC for the next OSGi Spec, what could it be (considering
> > what JMX offers)? I am asking cause I might be able to somehow try it in
> my
> > code and get some hints about how it may work.
> >
> > thanks guys and sorry for the long email. your thoughts and suggestions
> on
> > this matter are very much appreciated of course.
> >
> > -Nima
> >
> >
> > On Fri, Feb 19, 2010 at 8:48 AM, Ali Naddaf <al...@gmail.com>
> wrote:
> >
> > > I am also interested in knowing what one can do there. I have read that
> > J9
> > > has some extensions that enables a granular control of resources
> (memory,
> > > CPU) at the bundle level and ProSyst folks have some management tools
> > around
> > > that but that is the only JRE that I have heard whcih has that kind of
> > > capability, and of course that is not a universal feature of JREs so
> > won't
> > > help most people.
> > >
> > >
> > > On 2/19/2010 10:40 AM, Clifford H. James wrote:
> > >
> > >> I had wondered the same thing and at the time of my search all I found
> > was
> > >> that thesis project that you mentioned below.  Let me know if you find
> > >> anything because this is an area that I think needs some attention
> > (perhaps
> > >> from the OSGi Alliance people in an upcoming spec?) but I'm not sure
> if
> > the
> > >> "ThreadPool per bundle" that the author took doesn't create more
> > troubles
> > >> than it's worth -- it certainly isn't an unintrusive way to monitor
> > bundle
> > >> resource consumption.
> > >>
> > >> ~Cliff
> > >>
> > >> Nima Kaviani wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> I wonder if anybody knows of any profiling library / API that would
> > allow
> > >>> me
> > >>> to monitor the CPU and memory usages at a bundle level of
> granularity?
> > >>>
> > >>> I have already looked into JProfiler, but there are two problems with
> > >>> JProfiler. It is not a free tool, and also its profiling happens the
> > >>> level
> > >>> of objects and packages (the second issue could have been resolved if
> I
> > >>> could play around with the source code of course). I also found this
> > >>> thesis
> > >>> (http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf)  which takes
> a
> > >>> rather
> > >>> intrusive approach in modifying the internals of an osgi framework in
> > >>> order
> > >>> to support resource monitoring and profiling. Any help along this
> line
> > is
> > >>> very much appreciated.
> > >>>
> > >>> thanks,
> > >>> -Nima
> > >>>
> > >>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
> >
> > --
> > http://nima.magic.ubc.ca
> >
>



-- 
http://nima.magic.ubc.ca

Re: OSGi Bundle Profiling

Posted by teemu kanstren <tk...@gmail.com>.

Hello Nima,

 It would be interesting and nice to have some service available at the
container level to monitor the resources of a bundle as well as its
interactions more generally. I know I would like to use some stuff like
this.

But I have to agree it is hard to do without the ThreadPool approach. You
need some means to associate the executed code and the used resources to the
correct bundle. The ThreadPool seems to give you this. Do you have some idea
of the overhead it has as this seems to concern you? It does not sound like
it would be a big overhead.

It also seems like a lot of work to implement all the required functionality
for effective monitoring, such as proxy creations, modifications of the
container for the ThreadPool, instrumenting all object creation, etc. So it
would be nice to have this stuff implemented as services that could be used
as is, without need to redo many times. But I have no idea how to try to get
this into some OSGI spec. Maybe if you implement something, you could
provide it for the Felix implementation as a first step? Given some time
constraints, maybe you could also get some contributions from others.. :)

Teemu


2010/2/27 Nima Kaviani <ni...@gmail.com>

> Hello all,
>
> @Pierre, thanks for pointing out JVisualVM. It looks like an excellent
> tool,
> but it doesn't expose any API that I can use in order to programmatically
> monitor the behavior of OSGi bundles or do some further analysis on the
> collected data.
>
> Since Cliff and Ali also showed some interest in this topic, I thought I
> would discuss the results of my search for the past couple of days here to
> also benefit from your bright minds and come up with some solutions on how
> bundle profiling could be implemented for a SPEC 4.2 compliant OSGi
> framework.
>
> I examined some of the most up to date profiling tools, namely, JProfiler,
> JProbe, JVisualVM, JPI, JRockit Mission Control, and YourKit. The first
> three are proprietary and do not expose any API. JRockit Mission Control is
> free and has some sort of an API that could be used for profiling, but it
> only works with JRMC and when I ran felix against it, it drastically slowed
> down the performance of my application. JPI profiling results would only
> give me information on org.osgi.framework classes and nothing else! Not
> sure
> if this is because of having several class loaders for different bundles or
> whether there is something else confusing JPI. YourKit is apparently the
> only one which comes with an API but it does not provide monitoring at a
> level as fine-grained as JVisualVM (as Pierre said one can monitor
> processes
> in JVisualVM at the level of methods, classes, or packages, making possibly
> to cherry pick the classes or packages and associate them with bundles).
>
> I think what I am going to do is to write a bundle that would incorporate
> YourKit's API so that I can examine how closely I can resemble the behavior
> of a target bundle by monitoring its behavior as a matter of combining
> collected information from YourKit and information received from the
> BundleContext. So it would be like, inspecting the internal of a bundle by
> reflection and then matching them against the results of thread stack trace
> from the profiler. Do you guys have any better suggestion?
>
> @Cliff, I agree that thread pooling per bundle is an expensive task
> (specially with what YourKit offers, I have to inspect the thread stack
> trace in order to pool out the information that I require), but I couldn't
> think of any other way that would allow me to establish the associations
> between a process and its source bundle. so, I couldn't think of any
> alternative to what was suggested in the masters thesis I referenced
> earlier
> in this thread. Do you have a better idea? I mean, even if there is going
> to
> be a Profiling RFC for the next OSGi Spec, what could it be (considering
> what JMX offers)? I am asking cause I might be able to somehow try it in my
> code and get some hints about how it may work.
>
> thanks guys and sorry for the long email. your thoughts and suggestions on
> this matter are very much appreciated of course.
>
> -Nima
>
>
> On Fri, Feb 19, 2010 at 8:48 AM, Ali Naddaf <al...@gmail.com> wrote:
>
> > I am also interested in knowing what one can do there. I have read that
> J9
> > has some extensions that enables a granular control of resources (memory,
> > CPU) at the bundle level and ProSyst folks have some management tools
> around
> > that but that is the only JRE that I have heard whcih has that kind of
> > capability, and of course that is not a universal feature of JREs so
> won't
> > help most people.
> >
> >
> > On 2/19/2010 10:40 AM, Clifford H. James wrote:
> >
> >> I had wondered the same thing and at the time of my search all I found
> was
> >> that thesis project that you mentioned below.  Let me know if you find
> >> anything because this is an area that I think needs some attention
> (perhaps
> >> from the OSGi Alliance people in an upcoming spec?) but I'm not sure if
> the
> >> "ThreadPool per bundle" that the author took doesn't create more
> troubles
> >> than it's worth -- it certainly isn't an unintrusive way to monitor
> bundle
> >> resource consumption.
> >>
> >> ~Cliff
> >>
> >> Nima Kaviani wrote:
> >>
> >>> Hi all,
> >>>
> >>> I wonder if anybody knows of any profiling library / API that would
> allow
> >>> me
> >>> to monitor the CPU and memory usages at a bundle level of granularity?
> >>>
> >>> I have already looked into JProfiler, but there are two problems with
> >>> JProfiler. It is not a free tool, and also its profiling happens the
> >>> level
> >>> of objects and packages (the second issue could have been resolved if I
> >>> could play around with the source code of course). I also found this
> >>> thesis
> >>> (http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf)  which takes a
> >>> rather
> >>> intrusive approach in modifying the internals of an osgi framework in
> >>> order
> >>> to support resource monitoring and profiling. Any help along this line
> is
> >>> very much appreciated.
> >>>
> >>> thanks,
> >>> -Nima
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> http://nima.magic.ubc.ca
>

Re: OSGi Bundle Profiling

Posted by Marcel Offermans <ma...@luminis.nl>.

Hello Nima,

One project you could have a look at is I-JVM, a new JVM that was specifically designed to provide better isolation for OSGi bundles. It goes well beyond just profiling and resource tracking, but no doubt some of the techniques it uses might be interesting for you too.

See:
http://vmkit.llvm.org/publications/osgi_dsn.html

Greetings, Marcel


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: OSGi Bundle Profiling

Posted by Nima Kaviani <ni...@gmail.com>.

Hello all,

@Pierre, thanks for pointing out JVisualVM. It looks like an excellent tool,
but it doesn't expose any API that I can use in order to programmatically
monitor the behavior of OSGi bundles or do some further analysis on the
collected data.

Since Cliff and Ali also showed some interest in this topic, I thought I
would discuss the results of my search for the past couple of days here to
also benefit from your bright minds and come up with some solutions on how
bundle profiling could be implemented for a SPEC 4.2 compliant OSGi
framework.

I examined some of the most up to date profiling tools, namely, JProfiler,
JProbe, JVisualVM, JPI, JRockit Mission Control, and YourKit. The first
three are proprietary and do not expose any API. JRockit Mission Control is
free and has some sort of an API that could be used for profiling, but it
only works with JRMC and when I ran felix against it, it drastically slowed
down the performance of my application. JPI profiling results would only
give me information on org.osgi.framework classes and nothing else! Not sure
if this is because of having several class loaders for different bundles or
whether there is something else confusing JPI. YourKit is apparently the
only one which comes with an API but it does not provide monitoring at a
level as fine-grained as JVisualVM (as Pierre said one can monitor processes
in JVisualVM at the level of methods, classes, or packages, making possibly
to cherry pick the classes or packages and associate them with bundles).

I think what I am going to do is to write a bundle that would incorporate
YourKit's API so that I can examine how closely I can resemble the behavior
of a target bundle by monitoring its behavior as a matter of combining
collected information from YourKit and information received from the
BundleContext. So it would be like, inspecting the internal of a bundle by
reflection and then matching them against the results of thread stack trace
from the profiler. Do you guys have any better suggestion?

@Cliff, I agree that thread pooling per bundle is an expensive task
(specially with what YourKit offers, I have to inspect the thread stack
trace in order to pool out the information that I require), but I couldn't
think of any other way that would allow me to establish the associations
between a process and its source bundle. so, I couldn't think of any
alternative to what was suggested in the masters thesis I referenced earlier
in this thread. Do you have a better idea? I mean, even if there is going to
be a Profiling RFC for the next OSGi Spec, what could it be (considering
what JMX offers)? I am asking cause I might be able to somehow try it in my
code and get some hints about how it may work.

thanks guys and sorry for the long email. your thoughts and suggestions on
this matter are very much appreciated of course.

-Nima

On Fri, Feb 19, 2010 at 8:48 AM, Ali Naddaf <al...@gmail.com> wrote:

> I am also interested in knowing what one can do there. I have read that J9
> has some extensions that enables a granular control of resources (memory,
> CPU) at the bundle level and ProSyst folks have some management tools around
> that but that is the only JRE that I have heard whcih has that kind of
> capability, and of course that is not a universal feature of JREs so won't
> help most people.
>
>
> On 2/19/2010 10:40 AM, Clifford H. James wrote:
>
>> I had wondered the same thing and at the time of my search all I found was
>> that thesis project that you mentioned below.  Let me know if you find
>> anything because this is an area that I think needs some attention (perhaps
>> from the OSGi Alliance people in an upcoming spec?) but I'm not sure if the
>> "ThreadPool per bundle" that the author took doesn't create more troubles
>> than it's worth -- it certainly isn't an unintrusive way to monitor bundle
>> resource consumption.
>>
>> ~Cliff
>>
>> Nima Kaviani wrote:
>>
>>> Hi all,
>>>
>>> I wonder if anybody knows of any profiling library / API that would allow
>>> me
>>> to monitor the CPU and memory usages at a bundle level of granularity?
>>>
>>> I have already looked into JProfiler, but there are two problems with
>>> JProfiler. It is not a free tool, and also its profiling happens the
>>> level
>>> of objects and packages (the second issue could have been resolved if I
>>> could play around with the source code of course). I also found this
>>> thesis
>>> (http://www.vtt.fi/inf/pdf/publications/2008/P685.pdf)  which takes a
>>> rather
>>> intrusive approach in modifying the internals of an osgi framework in
>>> order
>>> to support resource monitoring and profiling. Any help along this line is
>>> very much appreciated.
>>>
>>> thanks,
>>> -Nima
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>

-- 
http://nima.magic.ubc.ca