Re: Speeding up GC

["David S. Miller" <davem at redhat dot com>]

   From: Paul Koning <pkoning@equallogic.com>
   Date: Tue, 4 Jun 2002 10:05:44 -0400
   
   It also depends on having a *hardware* dirty bit mechanism.  I don't
   know about Sparc, but -- for example -- MIPS doesn't have any.  You
   can simulate it by making the page read-only and taking the page fault
   on the first write, and indeed the documentation suggests this and
   describes how an OS could do it.  That of course wouldn't be all that
   cheap. 

Every software TLB cpu has this problem, and as you kind of hint at
the dirty bit is maintained in software.

I think messing around with dirty bits and OS interfaces to set/reset
them is absolutely the wrong path to go down.  This is going to make
GC much more complex from a per-host standpoint.  I also, for similar
reasons, think the SIGSEGV+mprotect idea is bad too.  I can guarentee
you we will need to disable this on half the platforms that have a
working mmap() because of either a) OS bugs in providing the correct
fault address to the SIGSEGV handler b) us not being able to figure
out how to make it work on a particular platform.

Really, the right answer, which I mentioned earlier, is to fix how we
allocate objects.  I mean it doesn't take a genius to figure out how
to plug all the holes on the RTL side right now.

1) Every function ever seen by gcc causes it to try and figure
   out if will return it's value in a register or not.  It does
   this via aggregate_value_p (), which if it will return into a
   register generates a hard REG rtl object EVERY CALL.

   FIX: Add new target interface that says "will return in reg"
        given function info.

2) Functions like loop.c:product_cheap_p() generate RTL to see
   if valid expressions of a given type can be created and if so
   see what it looks like.  Then the RTL is %100 forgotten.

   FIX: Create a "short-term" mode for GC allocation.  Enable this
   mode around such allocations.

3) SEQUENCE RTL objects are %99 short-term RTL and should die outside
   of reorg.c and ssa.c

   FIX: I have a patch which does which which I'll post for review
        to gcc-patches later today.

I could go on and on, just set breakpoints where RTL is allocated
and you'll see all the bonehead things the compiler does.  Another fun
exercise is to increase the size of each GC allocated object by
(N * sizeof(void *)) and tack on a record of N return addresses so
you can later see where unreferenced objects originate.  It's very
instructive.

To me, it seems much more prudent to fix the cause of the problem
instead of adding all of these page protection et al. games to GC.
What I am hearing right now from rth and others is "We allocate things
stupidly in the compiler, so we're going to fix the allocator."