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. 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. Hamad ________________________________ From: Ian Lance Taylor <iant@xxxxxxxxxx> Sent: Wednesday, May 22, 2019 8:02:56 AM 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 Tue, May 21, 2019 at 12:31 PM Hamad Ahmed <ahmed90@xxxxxxxxxx> wrote: > > That's why I am asking if it is easy to put in a compiler option like -fgarbage. When > > it is enabled, gcc should put in an extra instruction to zero out a register because > > gcc knows when a variable dies (won't be used anymore in the program) because > > it uses this information to do a lot of optimizations. I completely support adding better support to GCC for garbage collection--we could use it for Go. But this specific idea is just a part of that, and not the hardest part. The compiler is also fully capable of producing pointers that should hold a memory block live but do not actually point into that memory block--they point just past the end or earlier than the beginning, and the compiler uses offset calculations for all accesses. This does happen for certain kinds of loops. Also, some floating point values look exactly like pointers, so if you want reliable garbage collection you need to know whether a value is a pointer or not, but the compiler does not tell you that. Ian
