Re: stack calibration

[Neil Jerram]

Andy Wingo <address@hidden> writes:

> Hey Guilers,

Hi Andy,

In summary, I'm not sure I'm following the logic here...

> The recent commit to compile with the stack calibration file,
> 7ca96180f00800414a9cf855e5ca4dceb9baca07, breaks compilation because the
> compile scripts have hash-bang lines like this:
>
> #!/bin/sh
> # -*- scheme -*-
> exec ${GUILE-guile} -e '(@ (scripts compile) compile)' -s $0 "$@"
> !#

FWIW, I think this kind of incantation is really horrible.  Ditto for
usage of "guile-tools ...".  What kind of a scripting language is it
that needs to be bootstrapped by a different language?

Anyway, I see the breakage...  (Probably almost any change would break
something so fragile.)

> Also, it is a bit irritating to have to load a file just so Guile won't
> be broken (exaggerated wording, but I think that's what it is.)

I think you may be misunderstanding.  stack-limit-calibration.scm
should make precisely 0 difference on the "canonical build platform" -
which in practice means ia32 GNU/Linux.

As Guile stands (and notwithstanding your idea that we could use
getrlimit instead), we do hardcode _some_ stack depth limit.  Once
that was 20k, then 40k, and you're now suggesting 60k.  Those are
supposed to be values that will work on the canonical platform.

stack-limit-calibration.scm is all about scaling down/up the hardcoded
value for a non-canonical platform that might use more or less stack
on average than the canonical platform - e.g. because it has fewer
registers, because its pointers are twice the size (ia64) etc.

The primary purpose of stack-limit-calibration.scm is to allow "make
check" to succeed on those platforms, and it now makes sense to
generalize that to any other guile-using operations that we run during
the build - such as compiling.

It would probably also make sense to install
stack-limit-calibration.scm, so that 3rd party programs could also use
it; but we don't currently do that.

> So I have a proposal. We should set the stack limit to 60k words.

If we need 60k on the canonical build platform, we should have 60k.
No issue there.

>   Pros: 1) This way Guile will just work.

(For you.  Other platforms may still need stack-limit-calibration.scm.)

>         2) It's simple.
>         3) We avoid the evaluator this way.
>
>   Cons: 1) A stack-consuming process will take longer to catch.

Not a problem.  Any individual program can set the stack limit
differently, if they so choose.

> I cannot think of any other cons. GC just marks between the stack base
> and the stack pointer anyway. This would be 500 kB on x86-64, but a
> normal program would never use that, and last time I looked processes
> had 2 MB of stack by default anyway. It would be 250 kB on Linux.
>
> If we were really concerned about processes actually consuming all of
> their stack, we should use a value from getrlimit(2) instead.

I don't think that is the concern.  I think the idea is to catch
incorrectly written (i.e. usually non-tail-recursive) programs before
they crash.

Regards,
        Neil