Hi,
what about an "on-demand" profiling approach using btrace?
If it does work in OSGi, it could be used to trace latencies of method
calls, which then can be used in conjunction with thread stacks to find
out "hot-spots" and it also supports "best-guess" object memory
detection (but certainly not its origin).
But as others already pointed out there are a lot of stones in the way.
Also, even if you build up something with a lot of efforts you may just
find the obvious.
Cheers,
Ancoron
On 06/03/2012 06:33 PM, Raymond Auge wrote:
On Sun, Jun 3, 2012 at 9:02 AM, <[email protected]
<mailto:[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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
