[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: full moon, vm status update
From: |
Andy Wingo |
Subject: |
Re: full moon, vm status update |
Date: |
Thu, 16 Oct 2008 23:21:33 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
Howdy,
On Thu 16 Oct 2008 21:25, address@hidden (Ludovic Courtès) writes:
> 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?
I mean that instead of using scm_mark_locations() to mark the active
region of the allocated VM stack (vp->stack_base to vp->sp), we use
vm.c:vm_mark_stack() to mark that region precisely.
>> * 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?
For example, the fix to libguile/vm-engine.h:POP_LIST in 11ea1aba9eb9.
(POP_LIST): Hoo, fix a good bug: if CONS triggered a GC, the elements
of the list that had not yet been consed would not be marked, because
the sp was already below them.
@@ -275,10 +283,12 @@
do \
{ \
int i; \
- SCM l = SCM_EOL; \
- sp -= n; \
- for (i = n; i; i--) \
- CONS (l, sp[i], l); \
+ SCM l = SCM_EOL, x; \
+ for (i = n; i; i--) \
+ { \
+ POP (x); \
+ CONS (l, x, l); \
+ } \
PUSH (l); \
} while (0)
How's that for a hard-to-find bug!!!
>> * 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 hacked around this -- see what I've pushed to vm for more info.
>> 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?
> :-)
Oooh, just because you do dastardly things with the reader ;) You are
right. Code that causes side effects to the reader will not cause those
side effects until after the rest of the file is read, even if you
(eval-case ((load-toplevel compile-toplevel) ...)) it.
For what you want, I suggest #!lang things and reader macros (neither of
which we have yet).
Cheers,
Andy
--
http://wingolog.org/
- 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, 2008/10/16
- Re: full moon, vm status update,
Andy Wingo <=
- 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