advice on reducing C stack frame size?

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/

Re: advice on reducing C stack frame size?

[Han-Wen Nienhuys]

Andy Wingo escreveu:
> 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:
> 


> 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

This looks like a bug or an oversight.  -  14k is about 3500 SCM values; we surely
don't have that many local variables, so it looks as if there might be some 
macro that expands into a local array.   I'd have a look at the addresses of the 
different local variables to see where all that memory is going.  Also, look at
the preprocessed source and scan for array variables. 


-- 
 Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen

Re: advice on reducing C stack frame size?

[Neil Jerram]

2008/9/13 Han-Wen Nienhuys <hanwen@xs4all.nl>:
> Andy Wingo escreveu:
>>
>> 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
>
> This looks like a bug or an oversight.  -  14k is about 3500 SCM values; we surely
> don't have that many local variables, so it looks as if there might be some
> macro that expands into a local array.   I'd have a look at the addresses of the
> different local variables to see where all that memory is going.  Also, look at
> the preprocessed source and scan for array variables.

I agree.  I would first try to find out if the apparent 20k/14k is
real, and if so what accounts for it all.

      Neil

Re: advice on reducing C stack frame size?

[Ken Raeburn]

On Sep 13, 2008, at 12:56, Andy Wingo wrote:
> 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).

Aren't those the program counter addresses you're looking at?  Note  
that the value at #29 is in between #27 and #28.  Stack frames usually  
don't work that way. :-)

(gdb) bt
[...]
#7  0x00079691 in captured_main ()
#8  0x00077487 in catch_errors ()
#9  0x000796d2 in gdb_main ()      <---- pc address 0x796d2
#10 0x00001f1e in main ()
(gdb) x/20i gdb_main
0x79693 <gdb_main>:	push   %ebp
[...]
0x796c6 <gdb_main+51>:	mov    %ecx,0x4(%esp)
0x796ca <gdb_main+55>:	mov    %eax,(%esp)
0x796cd <gdb_main+58>:	call   0x7743a <catch_errors>
0x796d2 <gdb_main+63>:	add    $0x14,%esp     <---- insn to return to
0x796d5 <gdb_main+66>:	mov    $0x1,%eax
0x796da <gdb_main+71>:	pop    %ebx
(gdb)

Try "print $sp" or "info reg" at each frame to see the stack pointer.

Or you could try disassembling the entire thing, and scan for a regexp  
matching near the start of a function (say, symbol name, "+", one  
digit or a "1" and another digit, then ">", and an instruction that  
adjusts the stack pointer by a 3-digit value or more.  If it works,  
that may show you all the biggest-frame functions.

Ken

Re: advice on reducing C stack frame size?

[Andy Wingo]

Hi,

On Tue 16 Sep 2008 07:27, Ken Raeburn <raeburn@raeburn.org> writes:

> On Sep 13, 2008, at 12:56, Andy Wingo wrote:
>> So for example, just sitting at the repl, we have:
>>
>>    #28 0x001c48fc in vm_run (vm=0xb7f1ff58, program=0x8d53df8,
>>    #29 0x001bfcad in program_apply (program=0xb7ee2730, args=0x404) at
>>
>> The difference between #29 and #28 is the size of the vm_run() stack
>> frame (I think).
>
> Aren't those the program counter addresses you're looking at?

Probably so, stupid me. Showing my ignorance in public. 

They give us git-rebase so our patches can be perfect once pushed -- but
nothing for mailing lists! ;)

> Try "print $sp" or "info reg" at each frame to see the stack pointer.

Thanks!

Andy
-- 
http://wingolog.org/