Re: Re: A non-sucking garbage collector

Mark Hahn wrote:

...

> The only disadvantage of keeping an object read-locked too long is that
> it will keep old memory from being reclaimed.  The memory manager can
> complain if an arena is kept around too long by issuing a time-out
> error.  Obviously code should keep things locked for as short a time as
> possible but this is always a desirable goal for many reasons.

Sounds too good to be true. I'l believe it when I see it :-)

>>What stays is the 
>>double indirection all over the place. Do you think it is easy 
>>to undo this change if it turns out to be inefficient?
> 
> 
> It turned out to be only a few hours for me to split the objects into
> two parts for this scheme. One part is the non-copying tiny (8 bytes)
> part that stays in the global table and the rest is the data part that
> gets copied.  So I am not concerned about how hard it would be to switch
> back. 

Makes pretty much sense. Instead of Pythons complexity, you just
have all non-trivial objects as two parts. And by tagging you
get rid of all very small objects (I forgot if you used pointer
tagging? Anyway, this was the reason: python-dev discussed this
and the consequences for gc).

> I was quite surprised when the interpreter ran first try after the
> switchover. :-)  Writing the new garbage collector from scratch is
> turning out to be harder.

Good luck!  -- chris

-- 
Christian Tismer             :^)   <mailto:[email protected]>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/