fork()

[Tim Peters]

[Tim]
> 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>?

{Graham]
> 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.

Context:  this offshoot of the thread was talking about memory use after a
fork() call in a copy-on-write implementation of fork.  So long as
bookkeeping info is stored in object headers, "real GC" is at a real
disadvantage, in that respect, compared to RC.  Simply because RC won't
touch something unless *you* do.

LOR is an unrelated issue, and harder to analyze.  Yes, copying can speed
applications.  It can also slow them.  "Although copying garbage collectors
have predominated in the past, recent studies suggest that the choice
between mark-sweep and copying garbage collection may well depend as much on
the behavior of the client program as on the inherent properties of the
garbage collection algorithm" [Jones & Lins, "Garbage Collection", Wiley,
1996].  The hoary old theoretical arguments really aren't worth crap in this
field <0.5 wink>.

modern-hardware-is-too-hard-to-predict-ly y'rs  - tim