fork()

[Tim Peters]

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

[Matz]
> Indeed.  Though some "real GC" keeps mark bits in separated pages to
> avoid copying bunch of pages in such situation.

And, as at least Barry pointed out earlier, some refcounting systems
separate the counts from the objects they're counting, and largely for the
same reason.

> BTW, ref counting modifies objects for mere referencing, it causes
> copying too.

That's actually the observation that *started* "this offshoot of the
thread" -- but as if it were unique to RC, which it isn't.

>  Also, it would be performance pain if Python's global thread lock is
> removed someday, since ref counting requires mutual lock to protect
> ref count update.  I'm not sure this problem can be solved or not.

Back at Python 1.4, a set of patches was developed (by Greg Stein) that
*did* remove the global lock.  This meant fine-grained locking of other
stuff as needed, refcounts included.  The interpreter has changed quite a
bit since then, so old numbers aren't quantitatively relevant anymore; but
it was indeed a significant slowdown for single-threaded Python programs.

It's particularly acute for Python because *everything* "is boxed"; nothing
is exempt, and refcounting is never delayed.

OTOH, people who gripe about needing to keep refcounts straight in
extensions really haven't lived until they've wrestled with slamming in
exactly the right macros in exactly the right places to stop threaded
non-conservative GC from finding things in an inconsistent state <0.1 wink>.

what-end-users-don't-see-would-kill-them<wink>-ly y'rs  - tim