Re: Speeding up GC

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

   From: Marc Espie <espie@quatramaran.ens.fr>
   Date: Tue, 4 Jun 2002 11:20:35 +0200

   In article <20020603180553.A13829@redhat.com> you write:
   >A better way to do this is to actually compact the GC arena
   >and mark the pages read-only.  If the objects are modified,
   >the SIGSEGV handler marks the page read-write again and flags
   >the page as having been modified.
   
   Isn't that a bit expensive ? getting through a SEGV and a
   signal-handler is not especially fast on most OSes.
   
This, along with several other reasons, are why I think the
compacting allocator idea is going to be a net lose.

I think it is more worthwhile to clean up HOW we allocate
objects, especially "throw away" objects such as temporary RTL.

GC is a great way to simplify memory allocation, but it isn't an
excuse to do stupid things.  Many parts of the compiler do absolutely
stupid things which result in much fragmented GC memory.

A compacting allocator is just going to paper over the real problems,
not fix them.

Now, if we could use SIGSEGV handlers to totally eliminate the GC scan
itself, that I would buy as a performance win.  But you can't do that
and get the fine-grained in_use bitmap updates we get with current way
the GC scan operates.