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