Re: [gc-improv] Various fixes more or less finishing gc-improv development.

[Basile Starynkevitch <basile at starynkevitch dot net>]

Laurynas Biveinis wrote:
> I believe the branch now is in a state where it could be considered
> for 4.6 trunk merge. I will send separate e-mail about that later.
>
> Assorted fixes to everything GC related:
>
> - Un-breaking memory statistics (the ones enabled by
> --enable-gather-detailed-mem-stats) with ggc-page and partly with
> ggc-zone. Also I went through all the GC allocators and enabled
> gathering statistics with the ones that were missing it previously.
> (i.e. ggc_alloc_string)
>
> - Some fixes to memory statistics code in presence of PCH (common to
> ggc-page and ggc-zone).
>
> - Some fixes to ggc-zone In order to use MEM_STAT_DECL, I have
> replaced a few ggc.h macros with static inline functions. That in turn
> caused to define struct alloc_zone, rtl_zone, tree_zone and
> tree_id_zone unconditionally, no matter which allocator is used.
>
> - Properly use macros to inform Valgrind about poisoned regions in ggc-zone.
>
> - More fixes to ggc-zone memory statistics code in presence of PCH.
>
> - Some gengtype refactorings and fixes to output zone allocators properly.
>
> - Fixed one embarrassing wart from previous trunk merge.
>
> Bootstrapped and regtested undex x86_64-unknown-linux-gnu with
> --with-gc=page, --with-gc=page --enable-gather-detailed-mem-stats.
> Also built with --with-gc=zone and --with-gc=zone
> --enable-gather-detailed-mem-stats, however zone allocator seems to be
> broken with PCH even with all my fixes. I have stopped pursuing this
> further as ggc-zone seems to be broken on mainline too.

I am assuming this patch prefigures what you might later merge to the trunk.
If it is the case, please add more descriptive comments. In particular, 
I believe that each important macro or function should have a comment 
describing it. For example, your gc_alloc_atomic does not seems to be 
described (but in Boehm's collector a ten line paragraph describes 
various allocator routines).
Apart from having too few comments, you patch look great!

While both you and me know quite well the theory of garbage collection & 
memory allocation, this is not the case of every GCC contributor. And 
the current ggc.h also is lacking comments in my view. In contrast, 
Boehm's gc/gc.h has a much higher comment to code ratio!

Again, a very big thanks for your important work.

Regards.
--
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***