[Top][All Lists]

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

Re: [Gcl-devel] Re: gcl

From: Camm Maguire
Subject: Re: [Gcl-devel] Re: gcl
Date: 04 Jan 2002 15:39:09 -0500

Greetings!  Thanks for your input here Vadim!

OK, first some news: it appears that the libc2.2.4 on Linux is
basically fixed. In addition to the stack issue uncovered by Robert
Read, there is another small change in my tree against rsym_elf.c to
map _setjmp onto __sigsetjmp.  With these two changes, maxima's make
test runs without error for me on libc2.2.4.  Will be committing these
changes soon.

Given that one of our top priority items on which you had been working
may now be done (please confirm with the new commits when they are
in), would you perhaps like to look into this?  I think you have the
most experience with big memory usage.  You are after all the one who
came up with that gmp relocation test.  Perhaps you could start
digging into the code, and offering some thoughts on what memory
redesign would be necessary to get behavior more in line with CLISP

On some good advice from Peter van Eynde, it would seem that we will
always need a garbage collector (as opposed to malloc/free), and that
conservative ones fit C the best.  He recommends the Boehm libgc, and
it does appear to be used widely in a number of projects.  A version
even ships with the gcc compilers!  What's more, it is relatively easy
to implement, so I'm going to have a go at porting gcl to it as soon
as this libbfd stuff is done.  This gc can run incrementally too.  It
may have a significant performance impact.

But simply porting this gc will not solve the fragmented memory design
issue.  Can you help here Vadim?

Take care,

"Vadim V. Zhytnikov" <address@hidden> writes:

> Camm Maguire wrote:
> >
> > And then my wish list:
> >
> > 7) Clean the code!  No errors with -Wall, comment, etc.
> > 8) dlopen instead of fasload.
> > 9) look into the Boehm conservative garbage collector.  Can we do
> >    without a garbage collector, and just 'free' at the appropriate
> >    time?
> I think that garbage collection is very important issue for GCL
> future. And improving GC must get quite high priority
> in the task list. If we temporarily forget about other
> problems GCL is quite good and fast Lisp implementation
> unless time comes to make GC. As far as I understand
> at present memory in GCL is split in dozen of regions
> each serving as storage for data of some particular type.
> And memory can't be relocated between these regions
> at run time. It is not so bad for making some experiments
> with Lisp but it is bad for doing practical calculations.
> You can easily have a situation when you have plenty of
> RAM in general but run out of memory of some particular
> type X. So now to work with GCL you must permanently
> watch memory usage and adjust it manually according to you
> particular problem. This is not what the average user want to do.
> The problem is clearly visible when you run some
> large Lisp programs, like Maxima, on GCL.
> On GCL test run time strongly depends on the
> the amount of memory pre allocated at start time.
> Nothing like this is observed when running Maxima
> on other Lisps, say Clisp or CMUCL. This just proves
> that at present memory allocation and GC strategy
> in GCL is not so good.
> Vadim
> --
> [ Vadim V. Zhytnikov  <address@hidden>  <address@hidden> ]
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel

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]