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