bug#13088: stack overflow while compiling

[Stefan Israelsson Tampe]

Hi,

I added a patch to suggest a new environment variable.

   GUILE_STACK_SIZE_NSCM

If this is defined and setted to a reasonable number then this will be the number

of SCM (8 byte on a 64bit arch or 4 on a 32 bit arch) to allocate to the VM stack.

The naming might not be the best, we might want to name it VM_STACK in stead of stack.

anyway here is a patch. I tested it to the example in the beginning of this thread and it seams

to work just fine.

The intention is for this to be enough to close the bug.

/Stefan

On Wed, Dec 12, 2012 at 9:33 AM, <address@hidden> wrote:

-[ Tue, Dec 11, 2012 at 11:29:31PM +0100, Stefan Israelsson Tampe ]----

> Anyway in vm.c I changed the
> #define VM_DEFAULT_STACK_SIZE (64 * 1024)
>
> to
> #define VM_DEFAULT_STACK_SIZE (64 * 1024 * 64)
>
> and recompiled!

Oh, I hadn't realized you were speaking about the VM's stack. It all makes
sense now.
Any inconvenient to set this stack even bigger ? How many such stacks do we
have in a running environment ? One per thread ?

> Then I can compile to tree-il. Compiling all the way does not work well,
> But if you enter
> scheme@(guile-user)> (compile program #:to 'value #:opts '(#:partial-eval?
> #f #:cse? #f))  ;;NO OPTIMIZATION PASSES
>
> It will compile to.
>
> $7 = #<procedure 3708400 (proto server-port client-zone server-zone
> signature-id)>

Yes, I did this and as a result the compiled function was... 20% faster !?
(note that my bench exclude the compilation time, and uses get-internal-run-time
as a clock source).

Thank you very much for all these advices.
As usual, support from free software community is much better than it is from
any business I've seen :-)

stack-size.patch
Description: Binary data