This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Move loop structures to gc memory

On May 15, 2007, at 7:59 AM, Ian Lance Taylor wrote:
The bug, if it is indeed a bug, is that the set of GC roots is static.

I've been known to have a file static TREE_LIST of nodes that have have pointers to from non-GCed memory. Works just fine[1], though, kinda gross. While there is a single static head, the runtime list _is_ dynamic in nature. The list keeps GC from collecting any node of the list, and freeing is possible by just removing it from the list. Simple, easy to manage, arbitrarily extensible and does exact what you seem to want to do. For performance, one could have a vector, a splay, a hash or a red black tree... One is not limited to just a list.

So, either, I don't yet understand what you want to do, or that is the solution to the problem and this isn't a bug? I'd grant you that it is maybe inelegant.

If you want to have a dynamically allocated pointer into GC memory, you must put that pointer into GC memory itself.

Yes, this is true, but it doesn't mean you can't also have a pointer from non-GCed memory[1], which is the entire point of wanting to modify the set of GC roots?

Fixing that, and using it for the loop structures, would not be slower than using ggc_free.

I'd expect that to be about right. There are a couple of reasons why one may prefer ggc_free instead. If one wants to do a generation collector in the future, not having the objects managed by GC could make things tricky, or if one needs correctness across PCH writing and reading, letting GC manage is easiest way to go.

1 - You cannot do this across PCH write/read.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]