On Wed, May 22, 2019 at 3:41 PM Hamad Ahmed <ahmed90@xxxxxxxxxx> wrote:
>
> By rules I mean if you mess around casting pointers illegally that violate the C
>
> standard then the Boehm GC can't do anything about it. As an example,
>
> the C standard disallows casting a pointer to an int,
>
> doing operations on the int, and then casting back to a pointer. The reason is
> that suppose I have
>
> struct {int a; int b} x;
> int *u, *v;
> ...
> u = &x.a
> ...
> v = &x.b
>
> The compiler is allowed to store a single value for both u and v and keep
> track of the offset. Even without sharing, the bits of a
> pointer value may not actually be the address because it may be convenient
> for the compiler to have it point somewhere else and keep track of a known
> offset. Casting to an int and back can break GCC. You also talked about a
>
> similar case of the compiler keeping offsets instead of actual addresses when
>
> using loops. Boehm GC can deal with these compiler trickeries as long as you
>
> don't violate the C standard.
Thanks. Do you have a pointer to a description of how it does it?
> The type B error that I described is the GC detecting a 'false pointer' when it
>
> shouldn't e.g. if you have a float that looks like a pointer. That's the definition
>
> of a conservative collector, if you have things in memory that look like pointers
>
> then that's a death kiss. Nothing can be done about it and the programmer
>
> should be ready to accept this before using a conservative collector. GCC could
>
> tell the garbage collector that something is not a pointer, but then it won't
>
> be conservative garbage collection, it will be an exact garbage collection. (It
>
> would be nice to have it though). The issue that I am talking about is that if
>
> some variables die i.e. all references to them disappear or they won't be used
>
> in the program again, then the garbage collector should be able to collect
>
> them. But it can't if pointers to them are left on the register or the stack. It will
>
> only collect them if those registers or stack slots get overwritten. GCC does a
>
> lot of optimizations and sees no value in zeroing out registers or stack slots
>
> containing pointers to dead variables. But this feature should be put in to
>
> enable better garbage collection. This issue is different from the GC
>
> misinterpreting floats or other things as false pointers in memory. That is
>
> beyond the capability of a conservative GC. The issue here is GCC not getting rid
>
> of unneeded pointers. GCC should obey a space time safety guarantee i.e. make
>
> sure that if a variable is dead then all pointers it has of it should disappear after
>
> a certain time if not instantly.
You are distinguishing the cases, but either way you have a value in
memory or a register that looks like a pointer but is actually not a
(live) pointer. Either way the conservative collector is incorrectly
deciding that a value, that is not a (live) pointer is in fact a
pointer. I don't see the cases as fundamentally different.
Ian
