[Sbcl-devel] Re: GC

[Christophe R. <cs...@ca...>]

Daniel Barlow <da...@te...> writes:

> "Paul F. Dietz" <di...@dl...> writes:
>
>> * (progn (compile nil '(lambda (a) (+ a a))) (sb-ext::gc :full t))
>
> Or in my copy (which has a working variant of the RESCAN_CHECK turned
> on, and is also slightly further mutated but not I believe in any
> relevant way - oh how I wish I had the Intarweb again and I could
> check these things easily)
>
> * (let () (sb-ext:gc :full t)
>
> What?  This /isn't/ a competition to find the shortest form that'll kill
> SBCL's GC?
>
> There is a bug, yes.  I'm not sure where, but I am looking for it.  I
> suspect it's not in the last round of refactoring: more likely it's in
> some fairly old code (maybe CMUCL code, or maybe code I screwed up in
> some previous refactoring) and merely exacerbated by the last round of
> changes.  Untested, but I expect the relevant bits to back out if
> you'd like to return to the previous
> not-actually-reliable-but-still-better state are
>
> 1) revert gencgc_pickup_dynamic to the form it had in 0.8.7 
> 2) revert the (gc_alloc_generation == 0) clause of the very large
> if statement in gc_find_freeish_pages - and, if you like, the comment
> about things breaking randomly if it's omitted ;-)

There must be something else, though, because current sources on PPC
have acquired a suboptimality.

  * (disassemble '+)

  debugger invoked on a SIMPLE-TYPE-ERROR in thread 28422:
    Argument X is not a NUMBER: NIL

Why do I think this is connected?  Well,

  * (defun foo (x) x)
 
  FOO
  * (disassemble 'foo)
 
  ; 4001713C:       STW $LRA,4($CFP)            ; no-arg-parsing entry point
  ; [...]
  * (gc)

  * (gc)

  * (gc)

  * (disassemble 'foo)
  ; 4001713C:       STW $LRA,4($CFP)            ; no-arg-parsing entry point
  ; [...]
  * (gc)

  * (gc)

  * (gc)

  * (purify)

  * (disassemble 'foo)

  debugger invoked on a SIMPLE-TYPE-ERROR in thread 28422:
    Argument X is not a NUMBER: NIL

In words: running PURIFY appears to break the disassembler on purified
functions.  Before purification, SB-DISASSEM::CODE-INST-AREA-LENGTH
returns 408 for FOO; afterwards, it returns NIL.
CODE-INST-AREA-LENGTH appears to be a simple slot reference, so it
appears that purify isn't copying everything it needs to?  Or is
corrupting data?  Ugh.

I don't have sbcl-0.8.7 to hand; can someone with a PPC (preferably
MacOS X, to minimise the number of variables) version of that verify
whether it suffers from this problem?  sbcl-0.8.6 is known not to.

Cheers,

Christophe  
-- 
http://www-jcsu.jesus.cam.ac.uk/~csr21/       +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%")    (pprint #36rJesusCollegeCambridge)