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.
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.
Hamad
________________________________
From: Ian Lance Taylor <iant@xxxxxxxxxx>
Sent: Wednesday, May 22, 2019 3:11:42 PM
To: Hamad Ahmed
Cc: Andrew Haley; Florian Weimer; Alexander Monakov; Xi Ruoyao; gcc-help@xxxxxxxxxxx
Subject: Re: How to force gcc to blackhole registers so that things maybe garbage collected?
On Wed, May 22, 2019 at 12:23 PM Hamad Ahmed <ahmed90@xxxxxxxxxx> wrote:
>
> The Boehm GC deals with the fact that the compiler uses offset calculation for accesses. It couldn't possibly work if it didn't.
>
> There are two inverse kinds of problems:
>
> A. failing to detect a pointer when it should
> B. detecting a false pointer when it shouldn't
>
> If you had A, the collector would be
> unsound. It would collect things that it shouldn't because they are still in
> use. And it would attempt the reuse them. Programs would crash. If you follow
> the rules of the Bohem GC, it *is* sound. And programs don't crash. A pointer
> is only hidden from the GC if you illegally cast it away. The Boehm GC is
> carefully written so that it sees correct pointers.
What are the rules that must be followed?
> The issue of floats looking like pointers is type B. If you had B, then it wouldn't be
> unsound. It would just have a memory leak. It would fail to collect things
> that it could. This is the definition of an imprecise collect: it can mistake
> a non pointer for a pointer and thus fail to collect things that it
> could. Such a non pointer could be a double. It could be a long. It could be
> several adjacent chars or shorts or ints or floats.
>
>
> The definition of a conservative collector is that it can make errors of type B but not A.
>
>
> The issue at hand here is that pointers lingering in registers and stack are preventing collection.
Which, by your taxonomy, is an error of type B. Why is this
particular case more important than other type B errors?
Ian
