On Wed, Mar 12, 2014 at 3:59 AM, Jan Vrany <jan.vr...@fit.cvut.cz> wrote:
> Hi Eliot, > > > 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. >> > > That's of course important, I agree. But if one uses out-of-image tools, > this could be seen too, couldn't it? > If one uses tools like OProfile or cachegrind, all this data are > collected and available for analysis. There's no symbol table info in the executable for generated methods, so no. In those tools the data is just somewhere in memory, not ascribable to specific functions. Of course with my profiler I had to write that support. I don't know those other tools and so don't know if they allow import of labels to analyse jitted code. Brief googling seems to indicate that neither has support for labelling jitted code. Another is evolvability. Because it's written in smalltalk I can >> develop the tool quickly and do so while I'm using it. >> >> But this is because it's written in Smalltalk rather than because it > runs within the debugee/profilee, no? That's what I said, yes ;-) -- best, Eliot
