fork()

[Christian Tismer]

Guido van Rossum wrote:
> 
> Christian Tismer <tismer at appliedbiometrics.com> writes:
> 
> > If we have knowlegde of the internals of every Python structure,
> > and if there were no hidden internal references to Python
> > objects, then we could quite easily build a non-pessimistic
> > GC, without the need to be hardware specific, scan the stack
> > and so on.
> > You know that I have an (early) Python with no stack.
> > Would this help?
> 
> I don't see how: the roots you are looking for are all in the frame
> objects anyway.  (There are a few variables in the C stack of
> eval_code() but they point to objects that are also in the frame's list
> of local variables or on the eval stack in the frame.)

Correct. You are right. My version has some slight advantages
since it can release some objects earlier,
but that's no point here.

The problem which I was thinking about was how to detect
that a cycle can be safely removed. eval_code() is well-behaved,
but it cannot tell how it was called, and how many other
functions from extensions are sitting on the stack which might
have alive references.
My interpre^H^H^H^H^H^H^H^Hevaluator knows a bit more
about the objects which are created during its lifettime,
since its lifetime is so much longer.

I don't see it yet, but I guess that there comes some
helpful extra information for free.
By now I'm just to dumb too dumb to find it out.

> But here's another dumb idea based on the same premise (since this
> thread won't die anyway, I might as well join in :-).

...

> - Almost all cycles involve a dictionary, in practice (probably also
> an instance, but those cycles involving an instance always also
> involve a dictionary, since all references from instances go through
> dictionaries).  Why does this matter?  Because now I only need to put
> a mark bit in dioctionary objects, and I can maintain a list of all
> dictionaries instead of a list of all objects, and apply
> mark-and-sweep to it, without occurring overhead for all objects.

Considering a "typed" allocator:
Would be equivalent to know all heap pages which hold
dictionaries? Or is the mark bit needed alsewhere?

> (You can create a cycle using only lists, but I bet that happens only
> for demonstration purposes, as in ``a = []; a.append(a)''.  So I can
> live with not freeing such cycles.)

Would come for free, but well.

<snipped the best, but reserved for later thoughts/>

> Why this compromise instead of "true GC" like Java?  Because one of
> Python's main reasons of existence is its good integration with
> external C code -- in a glue language, you can't set the rules for
> management of all memory!

Very good. Like conservative for the outside (by not touching it)
and collaborative for the inside.

> May this thread spurn some code,

:-) chris

-- 
Christian Tismer             :^)   <mailto:tismer at appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.python.net
10553 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     not coding at all is proven to be the best time saver