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 - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen
