Hello skaller, Saturday, August 12, 2006, 12:34:54 PM, you wrote:
My point here is that actually this is a disastrous optimisation in a multi-processing environment, because in general, the assignment of a pointer means the store isn't write once.
:) all the variables rewritten is local to the function. _without_ tail call optimization, we create new stack frame for each recursive call. _with_ optimization, we just update vars in the first stack frame created because we know that these vars will not be reused after return from call
Yes, but this defeats the use of the kind of collector I attempted to describe.
The problem will occur if the 'stack' is aged: in that case the sweep can miss the mutation and reap a live object.
well, i don't know how updatable vars in stack interoperate with GC. let's someone else answer this question. but afaik GHC 6.5 supports multi-cpu execution of multiple Haskell threads (which makes it a better language for modern multi-core cpus), tail-call optimization and 2-generation GC (actually, it supports any number of generations). also, GHC supports mutable arrays. you search GHC bug tickets for one that optimized GC with mutable vars: in ghc64 _each_ GC, including minor ones need to scan _every_ updatable reference (IORef/STRef) and _each_ element of _every_ updatable array (IOArray/STArray) and this significantly slowdowns many programs, including GHC itself. in ghc65 better scheme now used -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com