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

[Camm Maguire]

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

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

Here's a schematic of GCL's memory layout:

.text:  
main                          (0x804ad30 in my image)
all compiled C files in o/
...
user_match                    (0x81870a0 in my image)
.data:                        (0x81a53a0 in my image)
intermixed typed pages
(i.e. cons, string, contblock...)
(contblocks hold loaded compiled
lisp objects, area malloced by
external libs, and, formerly,
bignums)
heap_end                      (0x8451000 in my image)
hole (512 pages)
rb_pointer (relblock area)    (0x865102c  in my image)
core_end                      (0x871d000  in my image)

which corresponds to a 7Mb+ DRS reported by 'ps axvwm'.  What is
interesting and beyond myunderstanding at the moment is that the image
size on disk is only ~ 4.5Mb -- there must be some sort of compression
going on I'd think.

In any case, the hole is in the image, allocated in the .data section,
but is not among the typed pages in the Lisp heap.  In particular, the
hole is not kept in contblock pages.  Hope this helps.  Suggestions
for improvements as always most welcome.

Take care,

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