Message361163
| Author |
vstinner |
| Recipients |
eric.snow, jeremy.kloth, jkloth, nanjekyejoannah, ncoghlan, vstinner |
| Date |
2020年02月01日.12:10:29 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1580559029.67.0.287103794693.issue39511@roundup.psfhosted.org> |
| In-reply-to |
| Content |
I vaguely recall discussions about immortal Python objects.
(*) Instagram gc.freeze()
* https://docs.python.org/dev/library/gc.html#gc.freeze
* https://instagram-engineering.com/dismissing-python-garbage-collection-at-instagram-4dca40b29172
(*) Python immortal strings
* PyUnicode_InternImmortal()
* SSTATE_INTERNED_IMMORTAL
* They are only destroyed if Python is compiled with Valgrind or Purify support: unicode_release_interned() function
(*) COUNT_ALLOCS
* When Python is built with COUNT_ALLOCS macro defined, types are immortal
* Many tests have to be skipped if COUNT_ALLOCS is used
* I plan to remove COUNT_ALLOCS feature in bpo-39489 :-)
(*) Static types
* Types which are not allocated on the heap but "static" are immortal
* These types cause various issues and should go away
* For example, they are incompatible with multi-phase initialization module (PEP 489) and stable ABI (PEP 384) |
|