On Wed, Mar 12, 2014 at 3:59 AM, Jan Vrany <jan.vrany@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