fwiw we added immortal objects to Pyston and haven't run into any issues with it. The goal is a bit different: to eliminate common refcount operations for performance, which we can do a bit more of because we have a jit. And we don't mind if unaware code ends up changing the refcounts of immortal objects since it's no worse for us than before.
So anyway maybe it's not super comparable for the issues discussed here, but at least we haven't run into any issues of extension modules being confused by very large reference counts. The one issue we do run into is that quite a few projects will test in debug mode that their c extension doesn't leak reference counts, and that no longer works for us because we don't update Py_RefTotal for immortal objects. kmod On Wed, Dec 15, 2021 at 2:02 PM Eric Snow <ericsnowcurren...@gmail.com> wrote: > On Tue, Dec 14, 2021 at 11:19 AM Eric Snow <ericsnowcurren...@gmail.com> > wrote: > > There is one solution that would help both of the above in a nice way: > > "immortal" objects. > > FYI, here are some observations that came up during some discussions > with the "faster-cpython" team today: > > * immortal objects should probably only be immutable ones (other than > ob_refcnt, of course) > * GC concerns are less of an issue if a really high ref count (bit) is > used to identify immortal objects > * ob_refcnt is part of the public API (sadly), so using it to mark > immortal objects may be sensitive to interference > * ob_refcnt is part of the stable ABI (even more sadly), affecting any > solution using ref counts > * using the ref count isn't the only viable approach; another would be > checking the pointer itself > + put the object in a specific section of static data and compare > the pointer against the bounds > + this avoids loading the actual object data if it is immortal > + for objects that are mostly treated as markers (e.g. None), this > could have a meaningful impact > + not compatible with dynamically allocated objects > > -eric > _______________________________________________ > 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/LVLFPOIOXM34NQ2G73BAXIRS4TIN74JV/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/RX7JKJTATP4IUIWB5SPUIARSYM2C56EQ/ Code of Conduct: http://python.org/psf/codeofconduct/
