gencgc/ppc fixups ... fix the allocator/gc on threaded builds. Whoops. ... STACK_GROWS_DOWNARD ... in pa_alloc/gencgc/!x86, actually do the stack manipulation more plausibly. (Don't carefully write the value we want to preserve past the end of the stack, for one) ... whitespace.
Merge Cyrus Harmon's 7th gencgc merge candidate ... with the addition of idempotent implementations of arch_clear_pseudo_atomic_interrupted() for sparc, mips, alpha and hppa. (the last three completely untested). ... many, many changes, most of which are documented in doc/internals-notes/GENCGC-PORTING-NOTES (This commit may break horribly. Please read, please test)
Merge fix from Peter Van Eynde (sbcl-devel 2006-02-11 "cosmetic room bug") for a cosmetic room bug. ... also fix a distinctly non-cosmetic scrub-control-stack bug resulting from the same issue. This scrubbing failure appeared to cause heap corruption in powerpc/gencgc test builds; I think I understand why. The Cheney GC zeros the unused parts of the lisp control stack after it has completed the garbage collection. This ensures that, if the active stack had no garbage pointers at the start of the collection, there is no region in the entire control stack (used or unused) which contains a garbage pointer, since every entry has either been scavenged or zeroed. But since by assumption we start off with no garbage pointers, by mathematical induction we never scavenge one, so everything is safe. GENCGC doesn't perform this zeroing. (Why?) However, SCRUB-CONTROL-STACK does, before a GC. This is slightly more dangerous, because we could in fact have incomplete stack frames lying below the stack pointer with an entry from a previous iteration of the heap, but I think it's OK by the same reasoning as before. Failure to zero the stack, however, does leave the possibility of bogus pointers open when stack frames are extended but not every stack slot has yet been written to. This wasn't so much of an issue when the stack is scanned conservatively and ambiguous roots caused pinning, but under a precise stack scanning regime disaster ensues.
Fix hideously embarrassing ppc assembly bug in reg_LRA computation. ... no longer go wrong if bit 15 of lra is set. (The symptoms from this have been reported many, many times: segmentation faults in the first triggered GC. Kevin Rosenberg reported it first from my trawl on sbcl-devel, but I think it's been known for longer than that. Previously it had been dismissed as gcc miscompilation problems, because the problem disappeared when using a different version of gcc, for any individual developer: in retrospect, the fact that it was our bug after all is pretty obvious from the fact that we were never able to characterize particular versions of gcc which were bad.)
Fix most use of slot-names colliding with external symbols / symbols accessible from CL-USER ... prefix most such slots by %; ... rename METHOD-COMBINATION-TYPE to -TYPE-NAME (as in AMOP FIND-METHOD-COMBINATION) ... only the TYPE slot in SPECIALIZER left to go, which is more complicated because in fact it's not a TYPE at all; more like a specifier (or maybe a typeoid)
Fix bug in method-metacircle/discriminating function update. ... start defining SAFE-FOO variants of method- and generic-function- accessors, concentrating the horribleness. At the moment, we have separate SAFE-FOO and EARLY-FOO logic; at some time in the future it might be worth coalescing the two. ... test cases. Include both Jean and Pascal's variants of the method code, and write similar generic-function code (which, admittedly, seemed to pass anyway).