Ronald Oussoren wrote: > > On 28 Apr 2020, at 20:38, Jim J. Jewett jimjjew...@gmail.com 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.
> … One reason is type.__subclasses__(), that returns a list of > all subclasses and when a type is shared between sub-interpreters the return > value might > refer to objects in another interpreter. That could be fixed by another level > of > indirection I guess. But extension types could contain other references to > Python > objects, and it is a lot easier to keep track of which subinterpreter those > belong to when > every subinterpreter has its own copy of the type. So the problem is that even static types often have mutable (containers of) references back into the heap, and with multiple interpreters, these references would have to be made per-interpreter? If I'm not still missing something, then that could get ugly, but doesn't seem any worse than other things sub-interpreters have to multiply. > ... “Never changing the refcount” could be expensive Absolutely! That has always been the problem in the past. > in its own right, that adds a branch to every invocation of Py_INCREF and > Py_DECREF. See > also the benchmark data in <https://bugs.python.org/issue40255 > https://bugs.python.org/issue40255> > (which contains a patch that disables refcount updates for arbitrary objects). The updated patch shows that not having to write the memory (and invalidate caches, etc) is enough to make up for the extra testing. https://bugs.python.org/msg366605 Obviously, that might not hold up on other machines, etc., but it is already good enough to be interesting, and there is room for additional experimentation. _______________________________________________ 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/X5GM3TSGD4XR3U6OGU533232FPKGB2LZ/ Code of Conduct: http://python.org/psf/codeofconduct/
