Speeding up ggc-simple on stage1

[Alexandre Oliva]

On Jan 14, 2000, Mark Mitchell <mark@codesourcery.com> wrote:

>   Another argument against this patch is that it makes it harder to
> debug; conceptually, the process is recursive, and its sometimes
> useful to be able to walk up the chain and see how you got where you
> are.

Consider the patch withdrawn, then.

>   I'm all for speeding up the compiler -- but I'm old-fashioned.
> Let's profile first, and attack the hot spots!

But attacking the hot spots is precisely what I'm doing.  ggc-simple
seems to be just too slow.  Whenever I attach gdb to cc1, it's one of
its functions that running.  This means the compilation is spending
too much time in it.  Whether that's just because of thrashing, or if
we could avoid some of the heap walks, that's something to be figured
out.


Another possibility is to try to implement some portable equivalent of
valloc.  In fact, Jeff has recently mentioned that valloc wastes a lot
of memory.  I believe that's because it ends up wasting a whole page
for the malloc data structure that precede each allocated page, or
something alike.  We might try to work around this by trying to find
how much of a page we can use so that we leave enough space for the
malloc data structures.

Afterwards, we may implement valloc atop malloc, by checking whether
the result we get is the beginning of a page boundary and, if it's
not, we realloc it to a smaller size so that the next allocation gets
a properly aligned data block.  Afterwards, we may release the
realloced block, so that it can be reused for smaller allocations, but
not for page allocations, since it won't be big enough.

Another possibility, taken by Kaffe as a fallback, is to always
request for one page more than the requested size, and to choose a
page-aligned address within the returned block.  It might work to
realloc afterwards to release any remaining bytes after the page we
wanted, as long as realloc doesn't decide to move the block around.
But we'd be wasting the bytes before the beginning of a page.


Do you think any of these fallback schemes is worth pursuing?  Would
it be reasonable (and/or difficult) to give up some bytes at the end
of a page so that stupid valloc/malloc schemes would not waste a whole
page for their internal data structures for each page we allocate?

-- 
Alexandre Oliva http://www.ic.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{lsd.ic.unicamp.br,guarana.{org,com}} aoliva@{acm,computer}.org
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them