gcl-devel
[Top][All Lists]
Advanced

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

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


From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] GCL memory allocation and GC problems
Date: Wed, 14 Jan 2004 07:54:56 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.5) Gecko/20031006

Camm Maguire ?????:
Greetings!

"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 :-).


OK.  But please compare current CVS GCL and GCL
right before hole size related commit.  Where these
contblocks in the latter image?

--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>





reply via email to

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