Python's garbage collection was Re: Python reliability

[Paul Rubin]

Scott David Daniels <scott.daniels at acm.org> writes:
> > 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.

Yes, I'm hypothesizing a native-code compiler as might come out of
the PyPy project.

> > 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.

I mean in cases where the compiler can determine that it's dealing
with small ints.  That might be harder in Python than in Lisp, given
how dynamic Python is.  

> > 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.

Yes, that would describe just about every cpu for the past 30 years
that's a plausible Python target.