On Wed, Dec 31, 2008 at 11:53:14AM +0200, Nikodemus Siivola wrote:
> On Tue, Dec 30, 2008 at 11:25 PM, Josh Elsasser <josh@...> wrote:
> > The room.test.sh test in 126.96.36.199 currently fails on OpenBSD/i386,
> > apparently due to ROOM consing excessively. The amount of space used
> > for bignum objects roughly doubles with each ROOM call until it
> > exhaunts the heap during the sixth call. If I add (gc :gen 1) to the
> > inner loop in room.test.sh then the bignum objects are collected each
> > time, a plain (gc) won't do it. A log with an unmodified room.test.sh
> > is attached.
> > Is it worth it to try to find the revision where this first started
> > occuring, or does anyone have a better suggestion?
> Finding the problematic commit would be good. As a starting point,
> here's a list of commits since 1.0 that have touched
I've done a bit of bisecting and narrowed it down to two commits that
appear to cause excessive cosning for me. room.test.sh finishes
quickly and with a reasonably-sized dynamic space up to the commit
prior to 188.8.131.52, which makes some sense based on what changed.
With a patch to revert that commit the test finishes normally up until
just before 184.108.40.206, which makes a bit less sense to me.
With both 220.127.116.11 and 18.104.22.168 reverted, HEAD runs room.test.sh
> I'm not averse to sticking a #+(and bsd (not darwin)) (gc :gen 1) at
> the end of ROOM as a temporary measure, though, if that fixes the
> problem (along with a honking big FIXME.)
> > Also, while testing I discovered that the idiot that chose the
> > addresses for the spaces on x86 (me) must have had his eyes closed at
> > the time. Attached is a patch to fix them, and allow heap overflows
> > to be handled(?) properly.
> Thanks! Merged as 22.214.171.124 despite the freeze -- overlapping spaces
> are quite nasty.
Thanks for committing it, I really don't know how I managed mess those
address up so badly.
> We should add some code to the runtime to check that the spaces don't
> overlap... :)
> Apropos, FreeBSD/OpenBSD/maybe-others-as-well problem in ROOM may have
> to do with the entire dynamic-space address range being bignums.
> Getting MAP-ALLOCATED-OBJECTS to use modular arithmetic for addresses
> would be good -- and probably fix the consing issue.
> > The THROW NO-SUCH-TAG tests in debug.impure.lisp fails as well. Is
> > this something that's worth fixing, or should it just be marked as
> > failing?
> I've marked it as failing to start with -- though it is worth fixing of course!
Thanks for this too, with the two revisions mentioned above reverted I
don't see any expected failures right now.