[Top][All Lists]

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

Re: [Gcl-devel] GCL memory allocation and GC problems

From: Camm Maguire
Subject: Re: [Gcl-devel] GCL memory allocation and GC problems
Date: 13 Jan 2004 16:57:43 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2


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

> Camm Maguire ?????:
> > Hi Vadim!  Finalizing the default holesize now and rereading your old
> > messages.  It seems as if you said no less than 1000 pages, and
> > approx. 1/10 MAXPAGE (here too, as well as growth maximum default) was
> > optimal.  I've looked at this, and it adds 2.5 Mb (on 6.2) to the
> > default build.  Is it worth it?  What do people think?  How often do
> > applications try to dramatically extend the core?
> > Take care,
> Take a look at (room) output for new GCL build.
> I see about 400 allocated pages for contiguous blocks.
> Why?  Where this pages come from?  This is quite

There are a few stray mallocs/alloc_contblocks which might be cleaned
up, but the vast bulk is 1) the bfd relocation table (~ 950k, 304
contiguous pages (due to page boundary alignment)), and 2) relocated
lisp object files, maybe ~150 pages.  We could redirect the former to
a static internal array, or simply mark the pages as t_other to save
gbc traversal time (as we know, contblock gc is the most expensive by
far -- perhaps a better algorithm can be found at some point).  I'm
reasonable confident we could do this in less memory, but the tradeoff
is in not having to support relocation code on 12 platforms :-).

> unexpected.   As far as I understand larger hole size
> doesn't increase neither image size nor RSS, it
> increases VM only.

This is not right, I believe.  You should try it (redefine in
object.h).  The heap, hole, and initial relblock area is added to the
.data section of the running executable via sbrk at the time of raw
image initialization, and then saved with save-system.  We could get
sophisticated and try to map the relblock area somewhere else to avoid
allocating the hole, but this would be involved.  I'm open to
suggestions as always, of course.

In general, I'd really appreciate someone doing a memory usage
comparison between recent GCL and say 2.3.8.  I'll try to get to it

Take care,

> -- 
>       Vadim V. Zhytnikov
>        <address@hidden>
>       <address@hidden>

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]