Greetings! 1) the hole is a speed size tradeoff - too small, and your always gc'ing the whole heap to move it and make a new one -- too large, and you waste space. Right now it scales as a percentage of the current working heap. Seems like it would be better to step down as one approaches maxpage usage, maybe a percentage of the minimum of the current heap and the complementary unused or available heap? Something like this can be added without too much fuss if we can agree upon what is desired.
2) I'm a little confused by the 138 million cons number for 2.6.7 and just wanted to point out two things a) conses are 12 bytes in 2.6.7, and b) static linking does not work (if I recall) out of the box. So this leaves 88 million unless you guys have backported some patches from cvs head, which is great if so. If so, and if they are very small and useful, perhaps they can go into 2.6.8. Take care, Robert Boyer <[EMAIL PROTECTED]> writes: > I'm not suggesting anything actually. There are too many > issues and variables for my little head. > > However, if someone is running ACL2 and they have hit some > sort of "too bad, you totally lose because you are utterly > out of space" message and it turns out that there are > 100,000 pages = 400 megabytes of precious, utterly empty > resource that could be used but are tied up in some stupid > mysterious and mystical nothing called "the hole" because > someone once said to himself: > > Now we increment the hole size to 20% of max-pages instead > of the default 10%. > > then someone else might say Yikes! Hmmm. > > I sort-of-think that I/we did determined that capping the > hole size at 10,000 is not likely to kill too many innocent > bystanders. But confirming a proposition such as: > > is likely not harmful for other users of ACL2 > > is probably independent of ZFC. > > Bob > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
