Re: full moon, vm status update

[Ludovic Courtès]

Hi Andy,

Andy Wingo <address@hidden> writes:

>   * The VM stack is now marked precisely.

Did you mean stack frame objects that link `program' object invocations?
I guess this stack is referenced by the C stack, so why does something
special need to be done?

>   * There is a now a debugging mode, currently turned on, in which we
>     try ensure that the top of the stack is non-NULL and that all
>     elements past the top are set to NULL. There are a number of checks
>     in various places that this is the case. The idea is to avoid lost
>     references when GC runs, and the heap structure's idea of the VM
>     registers is out of sync with what the VM regs actually are; or
>     there is some sloppy programming somewhere. When turned off, this
>     code incurs no overhead.
>
>     This mode helped to catch a number of stack GC bugs.

Are you referring to leaks due to a stack that contains references to
Scheme objects that have not been overwritten for a while?  Or are there
other bugs?

>   * All of Guile's test suites pass now, with (ice-9 ...) compiled,
>     including boot-9.

Woow!

> The ugly:
>
>   * Actually the bit about all of the test suites passing was a lie in
>     another respect: the elisp test fails, with a C stack overflow,
>     indicating too much recursion into the interpreter.

I've seen `elisp.test' trigger a stack overflow with the interpreter
more often than any other test.  Don't know why.

>   * I had to disable compilation of popen.scm in order to get the tests
>     to pass, as it was causing really strange, nondeterministic things
>     to happen. I don't know why.
>
>     My current speculation is that when you compile --with-threads, as I
>     do, that the socketpair between the signal receiving thread and the
>     main thread is not closed after the fork, therefore signals in the
>     child might reach the parent or vice versa, causing random code to
>     run which itself might cause VM problems.

Ouch, that's a tricky area, and I think Rob had some ideas about it (I
remember discussions on IRC about that quagmire).

> My goal is: correct execution of all existing code that:
>   * does not do runtime side-effects in macros
>   * does not call (the-environment)
>   * does not unquote in values into macros

How about code that does "(read-set! keywords 'prefix)" and the likes?
:-)

> Well that's a long enough update! Questions, comments, and help are most
> welcome.

You rock!

> Bytecode:
>
>    0    (late-variable-ref 0)           ;; `open-output-file'
>    2    (local-ref 0)                   ;; `file' (arg)
>    4    (call 1)                                              at 
> r4rs.scm:145:16

And that's very nice too!

Thanks,
Ludo'.