[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] New twc+ trial installed

From: Camm Maguire
Subject: [Gcl-devel] New twc+ trial installed
Date: 04 Jun 2005 12:59:59 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Robert Boyer <address@hidden> writes:

> Sorry that I probably won't be able to read my email between 5 a.m. Monday
> and noon Saturday.
> Is there a new twc at UT that I could be usefully testing over the weekend?
> Your amazing work is, well, amazing!
> Bob

Greetings!  OK, gcl-2.6.6twc+ is now installed at your site.  It
represents the current state of play on all fronts we've recently
discussed though alas still needs a very little work before committing
to cvs.  I've done some work regarding stability when the entire heap
is allocated, as well as trapping some such critical errors
gracefully.  In particular, I've relaxed the requirement that 50% of
the relocatable space be free at all times.  This was quite wasteful
in the large prime result you suggested, so instead I've allowed the
GC to proceed even if it cannot allocate enough relblock to mark the
current usage, on the possibility that most of  it could be garbage,
and aborting it there is not enough room for the mark.  A warning is
given regarding 'tight reloc gc' which we might want to eliminate or
modify.  (si::gbc x) does a cons gc on x=nil, a contiguous gc on x=t,
and a relocatable gc otherwise, where the nature determines what is
collected.  The tight gc works only for the later at the moment but
needs extending to the second by moving the mark table.  Also, there
is as yet one unfixed bug triggered by the big prime example when
(si::set-gmp-allocate-relocatable nil) is done.  This needs fixing too
before commit.  Otherwise it seems rather solid.  Always have problems
with the (room) formatting-- wish some format expert could help here.
Also, am experimenting with a default maxpage of 1G and a default max
C stack of 1G, adjusted at configure and runtime if necessary.  We may
pay a small performance penalty with the ugly huge type_map arrays
which we wanted to make dynamic eventually anyway.  These binaries
should be much smaller due to the immediate fixnums, but the cltl1
image is larger for some as yet unknown reason, but possibly just the
expanded type_map arrays.

Feedback most welcome.

take care,


Camm Maguire                                            address@hidden
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]