Bug#676979: sbcl: file nik.lisp for reproduction is included below

[Faheem Mitha]

On Wed, 9 Jan 2013, Christoph Egger wrote:

> Hi!
>
> 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.
                                                            Regards, Faheem