Hello!

Here’s a code coverage report for Guile’s Scheme code:

  http://www.fdn.fr/~lcourtes/software/guile/guile.lcov/

So here’s the idea: pick the red box of your choice and make it so that
next time it’ll be bright green.  :-)

The report was generated using LCOV on data produced using (system vm
coverage) in the ‘wip-coverage’ branch, like this:

  $ ./check-guile --coverage
  ;; wait...
  $ genhtml -o guile.lcov guile.info

(I cheated, though: I removed poe.test because of bug #29616 and
statprof.test because it was taking too long.)

It’s slow but manageable: 69mn on my 1.2 GHz laptop vs. ~1mn30s for a
non-coverage run, i.e., 46 times slower.

To achieve this high level of performance, vm_dispatch_hook () allocates
frame objects on the C stack instead of on the heap.  Thus the lifetime
of frame objects is limited to the hook invocation.  I think it’s a
necessary evil.

Another option would have been to not use frame objects at all and pass
hooks the FP, IP, etc.  However, hooks would have had to provide in
Scheme the functionality provided in C by frame objects, such as
‘frame-procedure’, the arithmetic in ‘frame-instruction-pointer’, etc.
In the end that would probably have been slower.

I think there’s room for optimization on the path to hook invocation,
but that’s probably not a high priority.

I’ll merge it when the “absolute path in .go” issue has settled and when
I’ve written unit tests.

Comments welcome!

Thanks,
Ludo’.

PS: Thanks to Andy for his tips and tricks to optimize the collection hook!

PPS: Initially I envisioned a hook written in a purely functional way,
     using delimited continuations to suspend/resume its data gathering
     job and a functional data structure to store that data.  But I
     realized that vlist-based hash lists are unsuitable for the kind of
     2-level map needed here (we map procedures to a map from IP to
     execution counts; updating execution counts would be very costly.)
     Thoughts?