On 04/03/14 17:37, Eliot Miranda wrote:
On Sat, Mar 1, 2014 at 4:09 PM, Jan Vrany <[email protected] <mailto:[email protected]>> wrote: Maybe I'm missing something obvious, but from my point of view the fundamental difference here is that with JVM's JPDA triggering of event actually **does not** affect the monitored system. If these events are handled by the image, it is quite tricky to figure out which one is caused by "application" and which one is caused by the event handling machinery. For instance, if (non-empty) method is called after a GC, this handler may trigger another GC, which may... That brings me to another, if you do in-image profiling (event handling), data could be quite different than what would you get using out-of-image profiler. <personal experience:> I've used (and implemented some :-) both - Smalltalk in-image tools and out-of-image tools, namely JPDA and DTRACE/STAP. For serious profiling and monitoring, I always use out-of-image approach if possible. I disagree.
Fair enough :-) What I use for serious VM profiling is a hybrid approach
that collects data in the VM but uses the image to display and interact with it. The VMProfiler, which is in CogTools in the VMMaker repository is IMNAAHO a very nice VM profiler.
Looks good, indeed.
In the VM there is a thread that interrupts the main VM thread periodically, sampling its pc and storing this in a circular buffer. The thread and buffer are manipulated by a couple of primitives. Alongside is a platform-specific plugin to reveal the dlls loaded in the VM. The JIT reports current machine code methods and PICs through a primitive.
Looks like everybody has a slightly different techniques and its own tools :-) I collect data in VM but the VM reports them to "outside" (via log file or kind of IPC). Then I analyze data post-mortem using various tools, some of them are hand-crafted, some not. I found
KCachegrind quite nice. Anyway, the interesting question to me is what are the advantages of your approach? Best, Jan
