garbage collector

[Alastair Reid]

On Thursday 18 September 2003 3:59 pm, Ross Paterson wrote:
> Someone here was building Hugs on powerpc-apple-darwin6.6, and getting
> INTERNAL ERROR: importEntity.  The import entity in question had been
> garbage collected.  Recompiling module.c without optimization avoids the
> problem, so my guess is that the optimizer's use of registers is confusing
> the garbage collector.  I'm starting to think that marking the C stack
> isn't working very well, and wondering if this is why optimization is
> turned off for some of the other files.


On RISC machines, it's quite common to use optimizations like this:

  for(i=0; i<n; ++i) { s += a[i]; }
==>
  for(i=0, p=a; i<n; ++i, ++p) { s += *p; }

Problem: instead of having a pointer to 'a', we now have a pointer into 'a' so 
a garbage collector might incorrectly discard 'a'.

On CISC machines, this optimization is used less often because array indexing 
costs less.


Hugs doesn't contain code like that for loop but every single heap dereference 
is implemented as an array indexing operation using macros that (from memory) 
look like this:

 #define fst(x) heapTopFst[x]
 #define snd(x) heapTopSnd[x]

I think the code that causes the problem is stuff like this:

  x = intOf(fst(snd(p)));
  y = pair(...);      // allocates some memory (and therefore may GC)
  z = snd(snd(p));    // calculation that has some subexpressions
                      // in common with x

On RISC machines, the common subexpressions detected are pointers into the 
heap whereas on the x86, the common subexpressions detected are indexes into 
the heap table.


We really ought to turn optimization off on all RISC machines in all the 
typechecking and compilation parts of Hugs.  We don't need to turn it off in 
the bytecode interpreter part because the interpreter doesn't use 
conservative GC.

--
Alastair Reid