ROOM conses like mad on FreeBSD

[Nikodemus Siivola]

From Christian Pape via sbcl-devel

"For me there is another problem with room on FreeBSD 7.0-RELEASE and
SBCL 1.0.23.

If I call ROOM several times SBCL goes into the debugger. The problem
was also in SBCL 1.0.22. Seems it was not in 1.0.10 (?).

The bytes in the (space total) line nearly doubles from call to call
of room (see below). I compiled SBCL from the ports, only 1.0.10 was
installed from a package for testing.

Thanks,
Christian.

This is SBCL 1.0.23, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (room)

Dynamic space usage is: 29,032,528 bytes.
Read-only space usage is: 3,528 bytes.
Static space usage is: 2,160 bytes.
Control stack usage is: 1,432 bytes.
Binding stack usage is: 344 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
  9,458,528 bytes for 11,502 code objects.
  6,634,768 bytes for 829,346 cons objects.
  3,423,112 bytes for 79,617 instance objects.
  3,108,928 bytes for 55,932 simple-vector objects.
  6,421,624 bytes for 183,604 other objects.
 29,046,960 bytes for 1,160,001 dynamic objects (space total.)
* (room)

Dynamic space usage is: 26,534,104 bytes.
Read-only space usage is: 3,528 bytes.
Static space usage is: 2,160 bytes.
Control stack usage is: 1,432 bytes.
Binding stack usage is: 344 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
 21,264,232 bytes for 2,629,258 bignum objects.
  9,454,176 bytes for 11,483 code objects.
  4,962,224 bytes for 620,278 cons objects.
  3,590,704 bytes for 91,467 instance objects.
  3,080,760 bytes for 55,110 simple-vector objects.
  6,014,304 bytes for 189,643 other objects.
 48,366,400 bytes for 3,597,239 dynamic objects (space total.)
* (room)

Dynamic space usage is: 26,547,832 bytes.
Read-only space usage is: 3,528 bytes.
Static space usage is: 2,160 bytes.
Control stack usage is: 1,432 bytes.
Binding stack usage is: 344 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
 57,227,008 bytes for 7,124,605 bignum objects.
  9,454,176 bytes for 11,483 code objects.
  5,001,784 bytes for 625,223 cons objects.
 13,293,352 bytes for 392,632 other objects.
 84,976,320 bytes for 8,153,943 dynamic objects (space total.)
* (room)

Dynamic space usage is: 26,550,552 bytes.
Read-only space usage is: 3,528 bytes.
Static space usage is: 2,160 bytes.
Control stack usage is: 1,432 bytes.
Binding stack usage is: 344 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
 130,218,824 bytes for 16,248,582 bignum objects.
  9,454,176 bytes for 11,483 code objects.
 19,509,904 bytes for 1,134,115 other objects.
 159,182,904 bytes for 17,394,180 dynamic objects (space total.)
* (room)

Dynamic space usage is: 26,569,128 bytes.
Read-only space usage is: 3,528 bytes.
Static space usage is: 2,160 bytes.
Control stack usage is: 1,432 bytes.
Binding stack usage is: 344 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.

Breakdown for dynamic space:
 278,202,968 bytes for 34,746,600 bignum objects.
 31,438,936 bytes for 1,381,801 other objects.
 309,641,904 bytes for 36,128,401 dynamic objects (space total.)
* (room)

Dynamic space usage is: 26,577,392 bytes.
Read-only space usage is: 3,528 bytes.
Static space usage is: 2,160 bytes.
Control stack usage is: 1,432 bytes.
Binding stack usage is: 344 bytes.
Control and binding stack usage is for the current thread only.
Garbage collection is currently enabled.
Heap exhausted during allocation: 0 bytes available, 8 requested.
 Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB LUB !move Alloc Waste Trig WP GCs Mem-age
  0: 262143 0 0 0 255650 0 0 0 0 1047141224 1176 2000000 0 0 0.0000
  1: 150084 11719 0 0 113 16 0 0 28 485880 42504 2000000 86 0 1.8389
  2: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
  3: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
  4: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
  5: 0 0 0 0 0 0 0 0 0 0 0 2000000 0 0 0.0000
  6: 0 0 0 0 6365 0 0 0 0 26071040 0 2000000 6284 0 0.0000
  Total bytes allocated=1073698144
GC control variables:
         *GC-INHIBIT* = true
         *GC-PENDING* = true
 *STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 1182(tid 673190144):
Heap exhausted, game over.
Welcome to LDB, a low-level debugger for the Lisp runtime environment.

[larryv (larryv)]

Isn't the case anymore on sbcl 1.0.30 on freebsd-x86 7.0

bisecting told it started to work in this commit:

commit 037bdbd3349aa8ca80c498337881ba9a3c5778dd
Author: Gabor Melis <email address hidden>
Date: Thu Mar 19 13:42:05 2009 +0000

    1.0.26.9: reduce consing in MAP-ALLOCATED-OBJECTS

    ... on platforms where dynamic space extends past fixnum range

    Thanks to Bart Botta for the patch.

[Gábor Melis (melisgl)]

Apparently it's mostly fixed as in consing is not so mad anymore.