Re: full moon, vm status update

[Andy Wingo]

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/