guile-devel
[Top][All Lists]
Advanced

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

Re: advice on reducing C stack frame size?


From: Han-Wen Nienhuys
Subject: Re: advice on reducing C stack frame size?
Date: Sat, 13 Sep 2008 15:48:37 -0300
User-agent: Thunderbird 2.0.0.16 (X11/20080723)

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 - address@hidden - http://www.xs4all.nl/~hanwen





reply via email to

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