[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: full moon, vm status update
From: |
Ludovic Courtès |
Subject: |
Re: full moon, vm status update |
Date: |
Thu, 16 Oct 2008 21:25:17 +0200 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
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'.
- full moon, vm status update, Andy Wingo, 2008/10/15
- Re: full moon, vm status update, Julian Graham, 2008/10/16
- Re: full moon, vm status update,
Ludovic Courtès <=
- Re: full moon, vm status update, Andy Wingo, 2008/10/16
- Re: full moon, vm status update, Neil Jerram, 2008/10/18
- Re: full moon, vm status update, Neil Jerram, 2008/10/27
- Re: full moon, vm status update, Andy Wingo, 2008/10/31
- Re: full moon, vm status update, Ludovic Courtès, 2008/10/31
- Re: full moon, vm status update, Andy Wingo, 2008/10/31