[Top][All Lists]

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

[Gcl-devel] Re: Minor: Error message Building GCL 2.7.0 ?

From: Camm Maguire
Subject: [Gcl-devel] Re: Minor: Error message Building GCL 2.7.0 ?
Date: 30 May 2005 17:34:48 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Robert Boyer <address@hidden> writes:

> > sane default heap/fixnum table size tradeoff.  I'd especially appreciate
> > ideas on this latter point.
> I'm reluctant to waste your time.  But since you asked, I take it that the
> issue is that the larger we make the maximum immediate fixnum the less heap
> we can have.  My intuition here is, at least at the beginning, do not reduce
> the heap size in any way.  Heap seems much more precious than speed.

OK, then it would appear that the strategy should be to make the
available GCL heap memory as big as possible, and then to place
immediate fixnums in any space which is absolutely inaccessible.

I've managed to get a preliminary build pushing DBEGIN on x86 down to
0 using linker scripts, (i.e. providing another 128M heap on this
box).  I propose making configure lower the DBEGIN to 0 if possible,
and then to probe to detect if there is a 'shared library ceiling' to
sbrk or whether the stack does not start at -1.  If either of these
holds, we use this area for the immediate fixnum table -- most likely
the latter in preference to the former.  If neither holds, and DBEGIN
is unmovable and non-zero, use the area below DBEGIN for immediate
fixnums, else default back to the 16k explicit table. I.e. on
conventional 32bit linux, this would produce a 512Mb immediate fixnum
table starting at 0xc0000000 (only half the space is usable if we
stick with a two word cons, as we need to be able to mark an immediate
fixnum in the cdr.)

Feedback as always most appreciated.

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]