(I just realized that we started discussing details of immortal objects
in the wrong thread -- this is Eric's overview thread, there's a
separate thread on immortal objects. But alla, I'll respond here below.)
On Wed, Dec 15, 2021 at 5:05 PM Neil Schemenauer <[email protected]
<mailto:[email protected]>> wrote:
On 2021年12月15日 2:57 p.m., Guido van Rossum wrote:
But as long as the imbalance is less than 0x_2000_0000, the
refcount will remain in the inclusive range [ 0x_4000_0000 ,
0x_7FFF_FFFF ] and we can test for immortality by testing a single
bit:
if (o->ob_refcnt & 0x_4000_0000)
Could we have a full GC pass reset those counts to make it even more
unlikely to get out of bounds?
Maybe, but so far these are all immutable singletons that aren't linked
into the GC at all. Of course we could just add extra code to the GC
code that just resets all these refcounts, but since there are ~260
small integers that might slow things down more than we'd like. More
testing is required. Maybe we can get away with doing nothing on 64-bit
machines but we'll have to slow down a tad for 32-bit -- that would be
acceptable (since the future is clearly 64-bit).
Allocating immortal objects from a specific memory region seems like
another idea worth pursuing. It seems mimalloc has the ability to
allocate pools aligned to certain large boundaries. That takes some
platform specific magic. If we can do that, the test for
immortality is pretty cheap. However, if you can't allocate them at
a fixed region determined at compile time, I don't think you can
match the performance of the code above. Maybe it helps that you
could determine immortality by looking at the PyObject pointer and
without loading the ob_refcnt value from memory? You would do
something like:
if (((uintptr_t)o) & _Py_immortal_mask)
The _Py_immortal_mask value would not be known at compile time but
would be a global constant. So, it would be cached by the CPU.