Update of /cvsroot/sbcl/sbcl
In directory sc8-pr-cvs8.sourceforge.net:/tmp/cvs-serv4379
220.127.116.11: update bug #108 (ROOM issues)
* 18.104.22.168 took care of the (SAP= CURRENT END) aver failure, but
other issues remain.
RCS file: /cvsroot/sbcl/sbcl/BUGS,v
retrieving revision 1.525
retrieving revision 1.526
diff -u -d -r1.525 -r1.526
--- BUGS 13 Jan 2008 18:08:01 -0000 1.525
+++ BUGS 14 Jan 2008 12:41:43 -0000 1.526
@@ -249,20 +249,17 @@
comfortable merging the patches in the CVS version of SBCL.
- (TIME (ROOM T)) reports more than 200 Mbytes consed even for
- a clean, just-started SBCL system. And it seems to be right:
- (ROOM T) can bring a small computer to its knees for a *long*
- time trying to GC afterwards. Surely there's some more economical
- way to implement (ROOM T).
- Daniel Barlow doesn't know what fixed this, but observes that it
- doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T)
- in a fresh SBCL causes
+ ROOM issues:
- debugger invoked on a SB-INT:BUG in thread 5911:
- failed AVER: "(SAP= CURRENT END)"
+ a) ROOM works by walking over the heap linearly, instead of
+ following the object graph. Hence, it report garbage objects that
+ are unreachable. (Maybe this is a feature and not a bug?)
- unless a GC has happened beforehand.
+ b) ROOM uses MAP-ALLOCATED-OBJECTS to walk the heap, which doesn't
+ check all pointers as well as it should, and can hence become
+ confused, leading to aver failures. As of 22.214.171.124 these (the
+ SAP= aver in particular) should be mostly under control, but push
+ ROOM hard enough and it still might croak.
When the compiler inline expands functions, it may be that different
RCS file: /cvsroot/sbcl/sbcl/version.lisp-expr,v
retrieving revision 1.3805
retrieving revision 1.3806
diff -u -d -r1.3805 -r1.3806
--- version.lisp-expr 14 Jan 2008 12:22:11 -0000 1.3805
+++ version.lisp-expr 14 Jan 2008 12:41:43 -0000 1.3806
@@ -17,4 +17,4 @@
;;; checkins which aren't released. (And occasionally for internal
;;; versions, especially for internal versions off the main CVS
;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".)