[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: May nearly have simple statistical profiler working (need help).

From: Neil Jerram
Subject: Re: May nearly have simple statistical profiler working (need help).
Date: 16 Jul 2001 19:35:49 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

>>>>> "Rob" == Rob Browning <address@hidden> writes:

    Rob> Neil Jerram <address@hidden> writes:
    >> Actually, having looked at your code, I see that this could be
    >> the problem.  `(make-stack #t)' will give you a stack from the
    >> current code position right back up to the most recent
    >> `(start-stack ...)'  expression.  For code executed from the
    >> REPL, this means everything back up to the `(start-stack
    >> 'repl-stack ...)' in scm-style-repl/-eval at line 2502 in
    >> boot-9.scm.
    >> Apply frame traps, on the other hand, are active within the
    >> dynamic scope of the `with-traps' expression in
    >> error-catching-loop at line 2268.  So, since

    Rob> I don't know if it matters, but I only use
    Rob> (trap-enable/disable 'apply-frame) where appropriate.  I
    Rob> don't fiddle with any other evaluator/debugger options (well
    Rob> actually, I guess I do in my .guile file...)

    >> and since error-catching-loop only calls its thunk inside
    >> with-traps, there will be a lot of applications for which the
    >> apply-frame trap will fire but which you'll never see in the
    >> stack from (make-stack #t).

    Rob> I'm not sure this is an issue.  In my code the apply-frame
    Rob> trap is only enabled whenever the profiler is active.  I turn
    Rob> it on in statprof-start, and turn it off in statprof-stop.
    Rob> (Actually, I also turn it off during some critical sections
    Rob> inside the handlers, but those should be balanced and
    Rob> transparent.)

OK, but the firing of apply traps requires both `(trap-enable
'apply-frame)' and `(debug-enable 'traps)' [SCM_TRAPS_P in C].  And
`with-traps' is basically

  (debug-enable 'traps)
  (debug-disable 'traps))

So, once you've done a `(statprof-start)', apply traps will fire for
any application inside the dynamic scope of the `with-traps' that I
mentioned before.  And this scope is slightly wider than that of the
`(start-stack 'repl-stack (primitive-eval sourc))'.  In ASCII art...

 Guile's stack base   (start-stack 'repl-stack ...)      code position
/                                 |                             |
|-------- stack-id #f (A)---------|-- stack-id 'repl-stack (B)--|
|----- traps disabled ------|------- traps enabled -------------|
|                           |     :                             |
|                    (with-traps ...)                           |
|                           |     :                             |

The profile signal handler can fire with the code position in any of
regions 1, 2 and 3; the trap handler can fire in regions 2 and 3.

`(make-stack #t ...)' will always give you either stack A or stack B,
but _never_ the two joined together.  If you get a stack B --
i.e. region 3 -- you're OK, since everything in stack B is also
subject to apply traps.  But if you get a stack A -- regions 1 and 2
-- some of the stack items that you count come from region 1, where
traps are not enabled.

    >> PS.  ISTR that Keisuke had some profiling code too; is your
    >> code related to his?

    Rob> Nope.  AFAIK, I'm the only one working on a statistical
    Rob> profiler right now.  I started trying to make an exact
    Rob> profiler, but I realized that that wouldn't work the way I
    Rob> wanted for tail-recursive code.  The way I was implementing
    Rob> the profiler, it would have killed tail-recursions and
    Rob> explode the stack.  (Not a very non-intrusive profiler really
    Rob> :>).

I'm afraid I'm missing something.  In what way is the trap handler
part of your profiler non-exact?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]