Re: [PATCH] Allocate all target globals using GC for SWITCHABLE_TARGETs

[Richard Biener <richard dot guenther at gmail dot com>]

On Sun, Jan 12, 2014 at 10:51 PM, Trevor Saunders <tsaunders@mozilla.com> wrote:
> 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.

I think you would need to have a list of object/finalizer per GC page
and do finalization at sweep_pages () time.

Yes, per-type pools would also work (for types with finalizers).

Or rework how the GC works - surely advanced techs like incremental
or copying collection might benefit GCC.

Richard.

> Trev
>
>>
>> Richard.
>>
>> >
>> > r~
>> >