Hi Jan, On Mar 6, 2014, at 2:29 PM, Jan Vrany <[email protected]> wrote:
> 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? One is interactivity. The tool supports drilling down to instruction level, which is good for critical code sequences such as method prolog. Another is comprehensibility. Because it can distinguish between generated machine code (specific methods and runtime routines), functions in the VM and other support code (including stuff like Linux on stack system call entry) one sees all activities in the VM presented meaningfully. Another is evolvability. Because it's written in smalltalk I can develop the tool quickly and do so while I'm using it. > Best, Jan Eliot (phone)
