Re: Conservative GC isn't safe

[Stefan Monnier]

> It's not just strings and buffers and intervals.

The case of intervals is different because pointers to them from the
stack aren't recognized by our conservative stack scanner (CSS), so they're
more at risk, regardless of funny compiler shenanigans.

> What about cons cells?  There's nothing wrong with getting a cons from
> something, doing something that might GC with its car, then doing
> something that might GC with its cdr.  There's nothing stopping the
> compiler from keeping a pointer to the cdr instead of the car and
> indexing when it's time to dereference the cons and get the cdr out
> of it.

Read Boehm&Chase's article: indeed, it's legal for compilers to do that.

But Emacs is not the only program using CSS, so there is some amount of
pressure to try and make sure C compilers don't make life impossible
for CSS.

> Let me ask again: we already have all the runtime data we need for more
> conservative GC. Where is the resistance to the idea coming from?

A few reasons I can think of for this inertia:
- The problem is hypothetical.
- Even if you pay attention to internal pointers, there are still
  (hypothetical) cases that won't be caught.
- Noone volunteered to write it.
- It will likely increase the CPU cost of stack scanning.
- It will likely increase the amount of garbage we erroneously keep alive.


        Stefan