Python's garbage collection was Re: Python reliability

[Scott David Daniels]

Paul Rubin wrote:
> Scott David Daniels <scott.daniels at acm.org> writes:
> 
>>Current speeds are due to deep pipelines, and a conditional in the
>>INCREF code would blow a pipeline.
> 
> 
> I think most of the time, branch prediction will prevent the cache
> flush.
But, branch prediction is usually a compiler thing, based on code
that is, in this case, a spot in the interpreter that is actually
taking both sides of the branch quite often.  If you split the
interpreter to have a "presumed int" side, you might do OK, but
that is not how the code works at the moment.

> Some implementations use the low order bits as tags with a tag==0
> meaning an integer.  That means if you have two tagged integers,
> you can add and subtract them without having to twiddle the tags.
You can do so only once you discover you have two tagged integers.
The test for tagged integers (rather, the subsequent branch) is the
thing that blows the pipe.

> The alternative (tag==1 means integer) means you don't have to mask
> off the tag bits to dereference pointers, and you can still add a
> constant to a tagged int by simply adjusting the constant
> appropriately.  
And this presumes an architecture which byte-addresses and only
uses "aligned" addresses.


--Scott David Daniels
scott.daniels at acm.org