This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: Why two heap segments?
- To: Greg Harvey <Greg dot Harvey at thezone dot net>
- Subject: Re: Why two heap segments?
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 14 Mar 2000 22:20:32 +0100
- Cc: Mikael Djurfeldt <djurfeldt at nada dot kth dot se>, jimb at red-bean dot com, guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <E12Uf0y-0001M0-00@mdj.nada.kth.se> <m3em9egqbi.fsf@behemoth.dethfart.org>
Greg Harvey <Greg.Harvey@thezone.net> writes:
> > I just had a look at how the current CVS Guile allocates heap.
> >
> > It actually starts up with two heap segments.
> >
> > Why is that?
>
> First heap isn't quite big enough? >:').
Yes, this is the reason.
> > Starting up with one heap segment which is sufficiently large for most
> > common tasks must make Guile more efficient, or...?
>
> It depends on how you mean more efficient (or common ;). Testing with
> my current version (gc'ified 1.3.4), starting up with a 524228 cell
> heap (- chunk headers, which eat up a little of that), I end up with
> no gc's for startup (this includes syncase, so it's larger than just a
> bare guile); if all that was needed was startup, do a little stuff and
> exit, this would be perfect, provided you can handle an ~9 meg
> process easily (only slightly less than my all day emacs,
> actually).
I'm not saying we should have a mastodont heap, just a heap large
enough so the "more heap" criterium isn't met. I adjusted the initial
heap size from 32768 to 40000. The result was that we allocate less
memory, don't get an extra heap, and anyway have some heap to do small
things in after startup.
However, Jim's reference to a different scheme of allocating heap
sounds better.
> http://home.thezone.net/~gharvey/guile/gc-alloc-fix.diff
I'll look at this. Thanks!