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: Copying collection and our ggc_collect practices

Zack Weinberg wrote:

Ok, so that's pretty easy to turn into a file-scope static as ggc
needs.  I seriously suggest you do a sweep, find all of these, and fix

Turning local variables into file-scope variables would however be a step backwards in terms of modularizing or library-izing gcc. You might say: don't worry about that, it will never happen, but similarly major changes (including library-izing cpp) have happened.

And of course using a file-scope global instead of a local variable
does hurt optimization.

The ideal solution would be to have compiler support for copying
or non-conservative gc, just as we have compiler support for exception
handling.  For example java uses a conservative non-copying collector
because it cannot be sure what the compiler does with locals.  There
are other applications that would like precise gc.

Unfortunately, compiler-support precise gc is difficult - and maybe
expensive.  The GNU Modula-3 people worked hard on this problem;
I don't really know what the resolution was.  And some people think
that the tables needed for precise gc with optimized code are
going to be so big that it's better to use conservative collectors

The work with dwarf-based unwind information could perhaps be
extended for precise gc.  The problems are related: for gc we
need to know at any given time (or at least any time when gc
may happen) which registers and stack locations contain pointers
to gc-collectible data.
	--Per Bothner

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