On Sun, Jan 12, 2014 at 10:51 PM, Trevor Saunders <tsaund...@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 <r...@redhat.com> wrote:
>> > On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
>> >> 2014-01-09 Jakub Jelinek <ja...@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~
>> >
