Plan for gc-improv merge

Laurynas Biveinis laurynas.biveinis@gmail.com
Mon Apr 19 17:34:00 GMT 2010


2010/4/19 Basile Starynkevitch <basile@starynkevitch.net>:
> Laurynas Biveinis wrote:
>> The goal of the branch is to make the type of GC-allocated objects
>> known to GC at allocation time, by changing the allocation interface
>> from
>> foo *x = (foo *)ggc_alloc (sizeof (x));
>> to
>> foo *x = ggc_alloc_foo ();
>
> Will the name of the marking routines, such as gt_ggc_mx_tree_node for tree,
> change?

No. At this time, only the allocation interface changes. The markers
remain the same.

> Also, I believe that
>   foo* y = ggc_alloc_foo ();
> should behave like the 4.5.0
>  foo* y = (foo *)ggc_alloc_cleared(sizeof(foo));
> that it, that it should *clear* allocated memory. Clearing memory is cheap,
> and allocating uninitialized memory could lead to hard to find bugs.

There are separate ggc_alloc_cleared_foo () allocators too. I am not
sure about clearing everything though. As I did the conversion I was
looking for alloc followed by memset to 0 patterns or struct fields
that were forgotten to unitialize, but did not find any bugs of this
kind. Clearing memory could be expensive for large blocks of memory,
if allocator does not page them in, but GCC does not have anything
approaching that, I think.

>> A few points of note:
>> 1) For some types (tree, rtx) it is required to specify allocation
>> size explicitly. I have introduced a new GTY attribute variable_size
>> for that.
>
> How is that handled by their ggc_alloc_tree? As a size argument?

Yes, reusing the same size argument that is passed currently.

> Also, it would be nice if the new ggc.h could define some preprocessor flags
> specific to the change, eg #define GGC_ALLOC_IS_TYPED 1, to enable coding
> plugins which could work on both 4.5 & 4.6

Why?

Thank you for your comments and support,

-- 
Laurynas



More information about the Gcc mailing list