>>> This patch adds a new GTY option, "atomic", which is similar to the
>>> identical option you have with Boehm GC
>>> and which can be used with pointers to inform the GC/PCH machinery that
>>> they point to an area of memory that
>> [...]
>>> This patch basically implements it, but at this stage requires you to
>>> explicitly tell gengtype that the
>>> pointer is atomic (and that is safe for gengtype to ignore the memory it
>>> points to).
>>
>> then should you not name the attribute "ignore"?
>
> Or even the existing attribute "skip"?
"skip" is different. With "skip", the pointer is completely ignored by GC/PCH.
In this case, we don't want
to skip the pointer; we want the pointer itself to be managed by GC/PCH, but
the memory *it points to* to not
be scanned for pointers. ;-)
In the example I gave,
struct GTY(()) my_struct {
...
unsigned int * GTY((atomic)) some_ints;
size_t count;
...
};
you'd allocate "some_ints" using, for example, ggc_alloc_atomic_stat(), which
already exists in the GC (even
if at the moment there seems to be no particular support for atomic allocation
other than the name of that
function, which allocates memory in the same way as for non-atomic allocation),
and which would put the pointer
under control of the GC; so it is freed when the GC decides that it is no
longer referenced; you don't free
it manually. That is different from "skip", which would make then pointer
simply invisible to GC (you'd allocate
it using malloc()), and you'd have to free it manually (or to never free it).
In practice, when the GC is doing its marking pass, and is marking a structure
of type "my_struct", if the
"some_ints" pointer has the option "skip", the GC would not mark it at all;
it's ignored. The option "atomic"
would cause the GC to mark the pointer but ignore what it points to. The
default behaviour is yet different;
it is to examine the memory it points to, mark any pointers in there, and then
mark the pointer itself
too. But because gengtype does not know, at the moment, how to examine
unsigned ints (you don't examine them,
because the pointer is atomic!), it will print a error saying that the pointer
type is uninmplemented, and abort
(a further step, after introducing the "atomic" option, would be to have the GC
automatically mark such pointers
as atomic, as explained in the original post).
To clarify, I didn't invent the word "atomic" - AFAIK it is the standard GC
naming convention for memory that contains
no pointers. It's the name used for this in Boehm GC (the most popular C/C++
GC), where the function is called
GC_MALLOC_ATOMIC(), and it is also the name for it in the GCC GC, presumably,
since there already is a function
"ggc_alloc_atomic_stat()" which presumably is meant to allocate atomic memory
(hard to say in the absence of
documentation and given that the implementation is identical to the other
memory allocation at the moment, but it's
a safe guess).
What is the problem with "atomic" ? I guess you find it confusing because it
makes you think of "atomic access"
to memory ? You are right that there is that potential for confusion. :-(
We could rename it, but then we'd want to rename the GCC
ggc_alloc_atomic_stat() function too, and I'm not entirely
sure it would make anything clearer ... as "atomic" is the standard word for
that. I think the best we can do is
provide good documentation.
So, I guess what I take from your comments is that I should update the
documentation in my patch to include
a short discussion of how "atomic" differs from "skip", since it doesn't seem
to be that obvious for people. :-)
But please let me know if I'm missing something.
Thanks
