Memory management (Was Re: [commited] Reduce memory overhead ofPRE bitmaps)

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 2004-09-07 at 18:20 -0700, Devang Patel wrote:
> On Sep 7, 2004, at 1:52 PM, Jan Hubicka wrote:
> 
> > Hi,
> > the attached patch move bitmaps used by PRE to obstacks to conserve
> > roughly 10% of GGC allocated memory.  I've bootstrapped and regtested 
> > it
> > on i686-pc-gnu-linux and will commit it shortly.  It has been approved
> > by Daniel on IRC.
> 
> I thought GCC is moving away from obstacks ?

In this case, it makes the most sense.  I can do the same thing without
obstacks, but it all just goes on a free list and never gets used, so it
gets wasted, whereas with the obstack, it gets freed.
> 
At one point, it was believed that GC was a magic bullet, and everything
should be gc alloced.
I believe we've created an existence proof that this is wrong.
At least, in the current implementation.
obstacks make sense for some things, object pools for other things, non-
fixed sized pools (with realloc and free) for other things, and gc for a
last class of things.

Let me list the problems (no comment on what effect they have, it's
certainly debatable) with gc-only.
1. We can't run collection often, it's too slow
2. The GC doesn't have very good locality.
3. Overhead on ggc-page can be somewhat costly unless your objects fit
into one of the existing size orders.
4. Anything that points to gc'd memory you want to keep must be gc'd as
well.

That's just off the top of my head.

> Side note: All these memory managers makes me dizzy sometimes :). It'd 
> be
> helpful if there is one document describing which one to use in which
> situations.

My opinion is that things go like this.
There is one unimplemented thing on the list, that i'm willing to
implement if people actually see a need (ie they want the realloc and
free);

Indeterminate lifetime objects:

These are objects that may be modified and become free at any point
during compilation.  In our case, that is mainly trees and RTL.
This class does *not* include objects that live only for a single pass,
that have some determinate but long lifetime, or go through accessors in
order to be freed (IE every single call that can cause one to go free
goes through a single function.

These objects should be GC alloced.

Fixed lifetime objects:

These are all other objects.
They come in several categories.

Fixed size, fixed lifetime objects:  These should be pool-allocated,
using alloc-pools.  It provides all the advantages of obstacks, and you
can free and reuse individual objects without having to blow the entire
thing away.  Also, we have much better stat tracking and memory checking
with pools.

Varying size, fixed (but short) lifetime objects:  Short here means one
pass, or part of one pass.
These objects should be either xmalloc'd or obstack'd. Probably
obstack'd if you need to blow away all of them at once, or xmalloc'd if
you can blow them away one by one.  Or, if we want better tracking of
memory stats for these objects, or better checking, i'm happy to
implement memory pools/arenas (ala apache, other compilers, etc) that
provide all the familiar malloc functions, but you can blow away an
entire pool at once when you want.

Varying size, fixed (but long) lifetime objects:
If you can reuse individual objects, you probably want to use a memory
pool/arena. But since you can't do that right now, your best bet is to
xmalloc/xfree them if possible, and obstack them otherwise.
If you can't reuse individual objects at all, obstack them.


In short, we gc alloc way too many things right now, given the
limitations of our GC.  In reality, we shouldn't be gc'ing things unless
we need to, until we have a state of the art collector that could handle
it (and even then, it's arguable that it's still stupid to do it).

If somebody wants me to write this up in some .texi file after we've
argued about the above categories and whatnot, i'm happy to do so.
Otherwise, i'll just throw it on the wiki.

HTH,
Dan


> 
> -
> Devang
--