[vide infra] >>> Sorry by the simplistic idea, but catching the execution of methods >>> with >>> AOP cannot help to measure their execution time? >> >> If method a of bundle A calls method b of bundle B, which in turn calls >> InetAddress.getByName(), then the execution time measured for a will >> include the execution time proper to b and the time taken to do the DNS >> lookup. Separating these out could be tricky. >> >> Generally speaking a bundle corresponds to a set of packages (either >> exported or private), so your best approach is probably to ask your >> favourite profiler to report results on a package basis. This breaks >> down >> of course if a given package name is (privately) present in multiple >> bundles, or when the same jar file is embedded into multiple bundles. > > True. > > The only special case is if all your bundles communicate with each other > via services. In that case, if you intercept all service calls, you can > use those interceptors to measure the time taken inside each bundle. > Adding those interceptors can be done at runtime.
Hi Marcel, Heaven forbid that my bundles should communicate with each other by any other means :-). Yes, if you clock all calls to and returns from all methods which implement service interfaces then you can calculate the time spent in each service (including calls to code on the system class path, embedded library jars, etc) - on a single-threaded system. You also need to instrument various methods such as wait(), sleep(), read() from sockets or ports etc. in order to eliminate them. In the multi-threaded case you have to collect the timelines on a per-thread basis, and when two or more threads are active at the same time you need to allocate the CPU time between them. On the whole I think these techniques can be used to gather useful information in a lab context, where you can run one bundle and mock all its dependencies; but to study the complete system you are going to need to use a profiler and/or instrument the VM. Regards Chris _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
