Re: [patch] Move loop structures to gc memory

[Alexandre Oliva <aoliva at redhat dot com>]

On May 16, 2007, Mark Mitchell <mark@codesourcery.com> wrote:

> So, it's important that the GC system know that there are roots in
> this temporary memory.

Yup.

> In our current system, you must GC-allocate this temporary memory.

This doesn't seem like the single root cause of the problem to me.

AFAICT, the root cause of the problem is that you can't dynamically
register and deregister GC roots.

If you could, then you could allocate objects in however way it seemed
reasonable to you, and you could register these objects with whatever
walk functions or GGC types you'd like to use for them, such that
GCable objects reachable from them would be marked as live.

You'd then have to be careful to decide which pointers in such objects
might point to GC-able memory and which must not, because our
collector is not conservative.  And you'd have to remember that such
dynamic roots wouldn't be preserved across PCH, because, well, they're
not managed by GGC.


So how about we introduce a new type:

struct ggc_dynroot_tab {
  void *base;
  gt_pointer_walker cb;
  struct ggc_dynroot_tab *next;
};

such that we could use it like this:

struct mydynroot {
  struct ggc_dynroot_tab gcroot;
  tree whatever;
};

  struct mydynroot *p = alloca (sizeof (*p));
  memset (p, 0, sizeof (*p));
  ggc_add_dynroot (&p->gcroot, p, walk_mydynroot);

  ...

  ggc_remove_dynroot (&p->gcroot);

or like this:

  struct ggc_dynroot_tab gcroot;
  tree whatever = NULL_TREE;

  ggc_add_dynroot (&gcroot, &whatever, walk_ind_tree);

  ...

  ggc_remove_dynroot (&gcroot);
  
FAICT all this would take in ggc-common would be trivial headless
linked-list implementations of ggc_add_dynroot and ggc_remove_dynroot,
and an additional look in ggc_mark_roots to call the callback for each
dynroot.


Using obstacks might be trickier, since you have to know the structure
of what you're supposed to walk.  But if you can write a walk function
for that, or get gengtype to do so for you, you're fine.


> If you're in the camp that wants to avoid ggc_free,

I'm not, I don't have any qualms at all with explicit lifetime
termination, especially when locality is known to be favorable to this
kind of memory management.

I was just trying to understand what the problem with allocating GGC
memory was.  I was only thinking obstacks, and that didn't seem
unworkable to me.  I hadn't considered alloca, but now I can see where
you're coming from, and I think the above will deal with it, no?

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}