If the object is going to live until the "end of time"
(process/runtime/whatever) then there'll never be a need to deallocate
it, and so there's no point counting how many references exist (and
ditto for anything that it references).
Currently, statically allocated types include references to
heap-allocated objects, and since different interpreters may use
different heaps (via different allocators), this means they can't share
the static types either. These references are for freelists, weak
references, and some others that I forget but apparently make it
unfixable. Those with a __dict__ object also need to be per-interpreter.
If statically allocated types were truly constant, that would be great!
Then they could be freely reused. The same applies for many of our
built-in non-container types too, in my opinion (and my goal would be to
make code objects fully shareable, so you don't have to recompile/reload
them for each new interpreter).
(For those who aren't following it, there's a discussion with a patch
and benchmarks going on at https://bugs.python.org/issue40255 about
making objects individually immortal. It's more focused around
copy-on-write, rather than subinterpreters, but the benefits apply to both.)
Cheers,
Steve
On 28Apr2020 1949, Paul Ganssle wrote:
I don't know the answer to this, but what are some examples of objects
where you never change the refcount? Are these Python objects? If so,
wouldn't doing something like adding the object to a list necessarily
change its refcount, since the list implementation only knows, "I have a
reference to this object, I must increase the reference count", and it
doesn't know that the object doesn't need its reference count changed?
Best,
Paul
On 4/28/20 2:38 PM, Jim J. Jewett wrote:
Why do sub-interpreters require (separate and) heap-allocated types?
It seems types that are statically allocated are a pretty good use for immortal
objects, where you never change the refcount ... and then I don't see why you
need more than one copy.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/MKMGRHYKA2WLQ6UPLJQS5TXCC7CFEN43/
Code of Conduct: http://python.org/psf/codeofconduct/
