Bug#676979: sbcl: file nik.lisp for reproduction is included below
On Wed, 9 Jan 2013, Christoph Egger wrote:
> Faheem Mitha <faheem at faheem.info> writes:
>> On Wed, 9 Jan 2013, Christoph Egger wrote:
>>> So actually it either needs to actually dfail to allocate the memory
>>> or it's platform-specific. I think I get the problem on a amd64 with
>>> few enough memory to trigger the Heap exhaustion
>> Hi Christoph,
>> Thanks for taking a look. The developers don't seem interested. What
>> is dfail?
> Just a d too much. In the first case the run of (main 10000) just went
> through and didn't cause a heap exhaustion while the second one was on a
> machine with way less memory and address-space (64bit 8GB RAM vs 32bit
> 1G RAM) and showed the hep exhaustion error.
Yes, I could not reproduce the problem with amd64 either. I'm not sure
why. I don't think memory has much to do with it. My machine has 4G. Also,
the SBCL heap size is fixed and cannot expand anyway.
>> The major issue is really that (gc :full t) breaks. Do you see that?
> I guess so. The end of the log is below:
Yes, that looks like what I got. If you can interest any of the SBCL
developers in this, please do. I think SBCL's garbage collection has major
problems, but this opinion does not seem to be shared by most people.
A separate but related problem from the (gc :full t) breakage is that if
large objects are allocated, then much of the time, the SBCL gc does
nothing. So, of course, after a few such allocations, it runs out of room.
Thanks for your interest.