This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Allocate all target globals using GC for SWITCHABLE_TARGETs
- From: Trevor Saunders <tsaunders at mozilla dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Sun, 12 Jan 2014 16:51:58 -0500
- Subject: Re: [PATCH] Allocate all target globals using GC for SWITCHABLE_TARGETs
- Authentication-results: sourceware.org; auth=none
- References: <20140107193939 dot GY892 at tucnak dot redhat dot com> <CAFiYyc1CWvKmhf12XRep3AwKGaVxC4QerHsco8kJVkZD7xxa5g at mail dot gmail dot com> <20140108124540 dot GG892 at tucnak dot redhat dot com> <20140108183415 dot GK892 at tucnak dot redhat dot com> <52CECD7B dot 8040707 at redhat dot com> <20140109163539 dot GI892 at tucnak dot redhat dot com> <52CED15B dot 5020401 at redhat dot com> <20140109233458 dot GN892 at tucnak dot redhat dot com> <52D02FEF dot 9060001 at redhat dot com> <CAFiYyc02wud4E1NBiDV1_GQTmC+rTLfuDFP979hd164KGCWX0Q at mail dot gmail dot com>
On Sun, Jan 12, 2014 at 02:23:21PM +0100, Richard Biener wrote:
> On Fri, Jan 10, 2014 at 6:37 PM, Richard Henderson <rth@redhat.com> wrote:
> > On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
> >> 2014-01-09 Jakub Jelinek <jakub@redhat.com>
> >>
> >> * target-globals.c (save_target_globals): Allocate < 4KB structs using
> >> GC in payload of target_globals struct instead of allocating them on
> >> the heap and the larger structs separately using GC.
> >> * target-globals.h (struct target_globals): Make regs, hard_regs,
> >> reload, expmed, ira, ira_int and lra_fields GTY((atomic)) instead
> >> of GTY((skip)) and change type to void *.
> >> (reset_target_globals): Cast loads from those fields to corresponding
> >> types.
> >>
> >> --- gcc/target-globals.h.jj 2014-01-09 19:24:20.000000000 +0100
> >> +++ gcc/target-globals.h 2014-01-09 19:39:43.879348712 +0100
> >> @@ -41,17 +41,17 @@ extern struct target_lower_subreg *this_
> >>
> >> struct GTY(()) target_globals {
> >> struct target_flag_state *GTY((skip)) flag_state;
> >> - struct target_regs *GTY((skip)) regs;
> >> + void *GTY((atomic)) regs;
> >
> > I'm not entirely fond of this either, for the obvious reason. Clearly a
> > deficiency in gengtype, but after 2 hours of poking around I can see that
> > it isn't a quick fix.
> >
> > I guess I'm ok with the patch, since the use of the target_globals structure
> > is so restricted.
>
> Yeah. At some time we need a way to specify a finalization hook called
> if an object is collected and eventually a hook that walks extra roots
> indirectly
> reachable via an object (so you can have GC -> heap -> GC memory layouts
> more easily).
I actually tried to add finalizers a couple weeks ago, but it seems
pretty non trivial. ggc seems to basically just allocate by searching
for the first unmarked block. It doesn't even sweep unmarked stuff, it
just marks and then waits for the space to be allocated over. I believe
it deals with size by using different pages for each size class? So even
if it did sweep it would be somewhat tricky to know what finalizer to
call. Perhaps a solution is to have separate pages for each type that
needs a finalizer, and be able to mark things as being in one of three
states (in use, needs finalization but not in use, finalized and not in
use). That might hurt memory consumption in the short term, but I think
finalizers will be really useful in getting stuff out of gc memory so
that's probably not too bad.
Trev
>
> Richard.
>
> >
> > r~
> >