advice on reducing C stack frame size?

[Andy Wingo]

Hi,

With a local patch, it seems that my C stack frames are getting large
enough to start hitting the stack overflow checks.

(In the future this won't be a terrible problem, as you won't be
recursively calling the evaluator the the vm then the evaluator etc too
much, but while we still have a fair amount of code being interpreted,
it is important.)

So for example, just sitting at the repl, we have:

[...]
    #27 0x0014e99b in scm_apply (proc=0xb7f0d718, arg1=0x404, args=0x404) at 
eval.i.c:1656
    1656            return scm_dapply (proc, arg1, args);
    (gdb) 
    #28 0x001c48fc in vm_run (vm=0xb7f1ff58, program=0x8d53df8, args=0x404) at 
vm-i-system.c:510
    510       *sp = scm_apply (x, args, SCM_EOL);
    (gdb) p sp - vp->stack_base
    $3 = 104
    (gdb) up
    #29 0x001bfcad in program_apply (program=0xb7ee2730, args=0x404) at 
programs.c:126
    126   return scm_vm_apply (scm_the_vm (), program, args);
    (gdb) p 0x001c48fc - 0x001bfcad
    $4 = 19535

The difference between #29 and #28 is the size of the vm_run() stack
frame (I think). It is about 20 kilobytes!!! In contrast, a deval frame
appears to be less, but still excessive:

    #19 0x0014b076 in deval (x=0xb7f3a478, env=0xb7ee2560) at eval.i.c:358
    358                 (void) EVAL (form, env);
    (gdb) 
    #20 0x0014e72e in scm_dapply (proc=0xb7f3a6d0, arg1=<value optimized out>, 
args=0xb7ee25d0) at eval.i.c:1858
    1858              RETURN (EVALCAR (proc, args));
    (gdb) p 0x0014e72e - 0x0014b076
    $5 = 14008

This is with gcc 4.3.0 20080428 (Red Hat 4.3.0-8).

My question is: what should I do about this? Wait for the runtime tuning
patches to land in master and then merge them? Assume that over time, I
will eliminate the need to recursively call the vm, perhaps by
eliminating calls to the interpreter? Change the code for the VM to use
less local blocks (like { SCM foo; do_something (); }) ?

Thanks for any insight,

Andy
-- 
http://wingolog.org/