Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation

[Nicholas N. <nj...@ca...>]

On Thu, 5 Jun 2003, Mike Bresnahan wrote:

> Perhaps I misunderstand how valgrind works.  I have the understanding that,
> using the synthetic CPU, valgrind instruments the application on the fly and
> stores the instrumented code blocks in a cache.  The author describes this
> process here http://developer.kde.org/~sewardj/docs-1.9.5/mc_techdocs.html.
>
> Do I misunderstand?

You are right, Valgrind instruments the app dynamically.

I think when Alex said Valgrind doesn't "instrument" anything, he meant
that you don't have to do anything explicit, in a separate step.

> Note that Quanitfy for Windows does not require a relink.  You just point it
> at an executable and off it goes.  First it instruments the executable and
> dependent DLLs and then it executes it.

Valgrind's approach -- dynamically compiling and instrumenting all code
every time -- is the most convenient for users.  No worrying about whether
an executable is instrumented or anything.

As for efficiency, it would be possible to have Valgrind save the code it
generates, so you could reuse it the next time.  But the dynamic
compilation + instrumentation phase typically only takes up about 10% of
the execution time for Valgrind (the Memcheck skin, at least) so doing
this wouldn't help performance much, but it would make the implementation
more complicated, and possibly make life more difficult for users.

Actually, thinking more, Valgrind's just-in-time approach could has
another efficiency advantage -- it only instruments the code that gets
executed.  This is good (especially space-wise) if you only use a small
fraction of a great big library.

N