Re: [Gcl-devel] Re: gcl

[Vadim V. Zhytnikov]

Camm Maguire wrote:

> 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
> et.al.?
>
> On some good advice from Peter van Eynde, it would seem that we will
> always need a garbage collector

Certainly yes. GC is essential part of any Lisp system. The only
alternative
I ever heard of  - to have really HUGE amount of virtual memory
and
just don't do any memory GC of freeing (not very practical
approach).

> (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?
>

I've been thinking about my possible contribution to GCL project
last days
and I was about to propose another task to me - to track down non
ANSI
and missing ANSI features in GCL. But as far as I understand
there is already
other person - Richard Leddy who is willing to take care of it.
Am I right about this?

As for GC issue the main trouble is that I'm not experienced C
programmer.
As Lisp programmer I see how GCL's GC works and I feel that I do
not
quite like it. But I'm not sure that I'm qualified enough to make
concrete
proposals how to rewrite it in C. I could do some investigation
about GC
methods in CLisp, CMUCL and possible other lisps and compare it
to GCL with the aim to understand what the difference is and what
can be done to improve situation. But certainly I can't do it
very 
quickly :-( 


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

--

[ Vadim V. Zhytnikov  <address@hidden>  <address@hidden> ]