fork()

[Vladimir Marangozov]

Graham Matthews wrote:
> 
> Tim Peters (tim_one at email.msn.com) wrote:
> : OTOH, in a straightfoward mark-and-sweep GC scheme there will
> : at least be a "mark bit" in each object header.  So under that,
> : or under any form of compacting GC, the *entire live object space*
> : will get copied, regardless of whether *you* reference anything in
> : it or not.  So if RC truly sucks, what does that make GC <wink>?
> 
> But the reality is that copying memory can in fact speed applications
> up! Think about locality of reference after you have copied all live
> blocks to the start of memory.
> 

True enough. At least, it sounds true and promising ;-)
However, locality of reference (LOR) is something quite hard to measure
in practice. One has to tweak the kernel to collect some stats on this,
and even if one achieves LOR improvements on a partuclar system, say
Solaris, it could result in a LOR degradation on Linux or Windows.
Not to mention that nowadays nobody wants to play this game...

I also thought that Python suffers from very bad LOR, but this is and
will remain speculation (as well as statements regarding RC, GC or
RC+GC) until someone proves that one strategy is better or worse
than the other, in the average case, on the average system.

Graham, you said that you won't contribute a RC+GC scheme to Python, despite
your positive experience. If you change your mind and consider
devoting some spare time to give it a try, I'll devote some spare
time to help you with Python's internals and we'll see whether we
could come up with something viable, which could compete with the
actual RC scheme alone. Does this sound constructive enough? :-)

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov at inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252