guile-devel
[Top][All Lists]
Advanced

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

Re: Stack calibration


From: Neil Jerram
Subject: Re: Stack calibration
Date: Sun, 12 Oct 2008 16:59:05 +0100

Hi Ludovic,

2008/10/11 Ludovic Courtès <address@hidden>:
>
> The approach looks good to me.  It's just annoying that
> `SCM_CHECK_STACK' (adding a slight overhead) and "threads.h" have to be
> modified.
>
> Instead of storing the high water mark in threads, could we have
> `%get-stack-depth' and call it from somewhere deep in the code (similar
> to what was in your previous patch)?

Here's how my thought process went, in response to this.  I only
record because I think it's ultimately quite amusing (at my own
expense!)...

<imagine cinematic thinking effect>
Goodness, that Ludovic, can't he ever just be happy with what I've proposed...

...he does have a point though, there could be a performance impact of
the high water mark tracking... (and also, FWIW, I'm a bit worried
about the number of times we call pthread_getspecific() in mainline
code - is that efficient?)

...perhaps the high water marking tracking could be global, instead of
per thread; that would avoid adding a field to the thread structure,
and would still solve the main problem...

...oh, but that would require a mutex [which is vastly more inefficient]...

...well perhaps we could have an optional callout to Scheme, and do
the tracking in Scheme; then in the mainline case we'd still only be
checking one variable for being non-null, and the detail of whether
it's per thread, or if we need a mutex, can be delegated to the Scheme
code...

...oh but hang on, we already have arbitrary callouts to Scheme: the
evaluator traps!
</imagine cinematic thinking effect>

So yes, I think we can actually do this without any change to the C
code except adding %get-stack-depth, by using an evaluator trap.

> In that case, instead of using a void port for the REPL's output, we
> could for instance use a soft port and measure the stack depth from
> there:
>
>  (let ((before (%get-stack-depth))
>        (after  #f)
>        (port   (make-soft-port (vector (lambda (chr)
>                                          (set! after (%get-stack-depth)))
>                                        (lambda (str)
>                                          (set! after (%get-stack-depth)))
>                                        (lambda ()
>                                          (set! after (%get-stack-depth)))
>                                        #f #f #f))))
>    (with-output-to-port port
>      (lambda ()
>        (with-input-from-string "\n" top-repl)))
>    (abs (- after before)))

Cunning idea, but I'm pretty sure it wouldn't be effective, because
the reports from people who have seen Stack overflow during 'make
check' show that it occurs in a chain of module using: (top-repl) -
(use-modules (ice-9 debug)) - ... - before the REPL reaches the point
of printing anything.

Evaluator traps, on the other hand, will catch everything.  (At the
cost of running very slowly, but I think that's OK for just this one
calibration step.)

>>  BUILT_SOURCES = cpp_err_symbols.c cpp_sig_symbols.c libpath.h \
>>      version.h scmconfig.h \
>> -    $(DOT_X_FILES) $(EXTRA_DOT_X_FILES)
>> +    $(DOT_X_FILES) $(EXTRA_DOT_X_FILES) stack-limit-calibration.scm
>
> As Greg suggested, this could be in `check_DATA' or something like that.

Yes, but thanks for the more specific hint!

>> +;; This is the value of top-repl-hwm-measured that we get on a
>> +;; `canonical' build platform.  (See text below for what that means.)
>> +(define top-repl-hwm-i386-gnu-linux 9184)
>
> I'd tend to use the actual GNU triplet, like `i386-pc-linux-gnu'.

OK, will do.

> Thanks for working on it!

Thanks for not being happy!

    Neil




reply via email to

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