Re: Reducing memory consumption

[Jeffrey A Law <law at cygnus dot com>]

  In message <20000318101125O.mitchell@codesourcery.com>you write:
  > I don't think there's any point in that.  Just call the existing
  > ggc_collect.  We already have enough parameters to tweak: the minimum
  > size at which to do GC, and the expansion factor.  There's no real
  > reason to have a different expansion factor in other situations.
  > 
  > Before we get to the next major release, we need to profile, figure
  > out why things are slower and bigger, and take appropriate action.
  > I'll bet that GC is not really the cause of either the slowdown or the
  > size expansion, but we won't know until we profile, and experiment.
  > 
  > That said, your patch is basically a good idea.  Put it in, but
  > without the new function; just call ggc_collect.  Right now, we do our
  > first collection at rougly 4MB; it might well be that we should set
  > this to (say) 16MB instead.  Ideally, lots of small files, especially
  > in C, would require no collection at all.
But that will completely hose some systems that I actually still use
(some 4.3/4.4 m68k boxes I use for m68k testing).  They're already a bear
to bootstrap because of the increase in memory use due to GC.

Basically on those boxes GC effectively partitions memory into stuff that
in managed by GC and memory which is not managed by GC.  And because we
have to use valloc the amount of memory held by GC is actually 2X what it
should be (go look at how valloc works when you ask for a page of memory :(. 

Right now we hold a minimum of 4M, which is actually 8M and in practice it's
more like 12-16M.  Then when we try to xmalloc some reasonably sized data
structure in one of the optimizers there isn't a contiguous hunk of
malloc-able memory left and the allocation fails.

Yes, this really happens.  To bootstrap on those boxes I have to turn on
always collect and usually make the collection threshold very small.

So, before we start thinking about increasing the collection threshold we
need to be *very* careful that we don't hose even more systems.

jeff