gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: gcl


From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] Re: gcl
Date: Tue, 01 Jan 2002 21:23:20 +0300

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> ]







reply via email to

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