Compacting GC interacting with new codegen strangely

[Simon Marlow]

Hi Edward,

Well done for tracking down the bug!

On 06/03/11 15:36, Edward Z. Yang wrote:
> Excerpts from Edward Z. Yang's message of Sat Mar 05 15:00:03 -0500 2011:
>>      2. Change the code generator to not do untagged spills.
>
> I tried a brief patch to do this, but the result segfaulted, and I decided
> (1) might be more fruitful.

The GC invariant is currently that all pointers to heap objects are 
correctly tagged; this invariant is assumed and maintained by the GC. 
So we either have to do (2), or relax the invariant.  Relaxing the 
invariant is difficult - I know this, because we originally didn't have 
this invariant (tagging was supposed to be optional), but we were forced 
to add it to make things work. Some of the background is in the 
commentary page about pointer tagging.

>>      1. Investigate the operation of the compacting GC more closely
>>         and figure out why it is adding a tag,
>
> I have a question about the compacting GC: suppose I have a stack location
> that points to an info table. I have some pointers pointing to it with tag bit
> set to 0, and some other pointers pointing to it with tag bit 1.  Will the
> compacting GC ever tag some of those former pointers, as a result of threading
> or such?  Is this situation bad juju?

Yes, and this is one reason for the invariant.

> The plan is that I'm going to take my extensive notes from backwards analysis
> and rewrite them into a coherent forwards story about the evolution of the
> memory on that fateful GC, and hopefully that will clarify things a little
> better.

(2) is the only way I think.  But I agree it is somewhat worrying that 
we now have a delicate invariant on the code generator.

Cheers,
	Simon