From: Christophe R. <cs...@ca...> - 2004-01-08 14:42:29
|
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) |