On Wed, 9 Jan 2013, Christoph Egger wrote:
Hi!
Faheem Mitha <[email protected]> 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
_______________________________________________
pkg-common-lisp-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-common-lisp-devel
