[Tim] >> But I don't know what you mean by "access memory in random order to >> iterate over known objects". obmalloc never needs to iterate over >> known objects - indeed, it contains no code capable of doing that.. >> Our cyclic gc does, but that's independent of obmalloc.
[Antoine] > It's not. Cyclic GC needs its own linked lists *because* the allocator > doesn't allow it to iterate over allocated objects. The doubly linked lists in gc primarily support efficient _partitioning_ of objects for gc's purposes (a union of disjoint sets, with constant-time moving of an object from one set to another, and constant-time union of disjoint sets). "All objects" is almost never interesting to it (it is only when the oldest non-frozen generation is being collected). Between collections, the partitioning is by generation. During a collection, the youngest generations are combined into one, and then that's sub-partitioned in various ways as collection goes along, ending with a partition into reachable and unreachable objects. In between, ephemeral partitions are constructed (e.g., the set of "tentatively unreachable" objects). None of that was driven by obmalloc's (or malloc's) inability to iterate over objects. Doubly linked lists were the obvious way to implement the required operations on partitions efficiently and simply. In any case, it appears to be "a feature" now that people can use any flavor of the malloc family they like in CPython, so I expect that any attempt to tie cyclic gc to a specific flavor of malloc would be a very hard sell. Which, BTW, was the intended meaning of "independent": cyclic gc right now couldn't care less which version of malloc a user plugs in - nor could obmalloc care less which cyclic gc algorithm is used. _______________________________________________ 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/OR4NFZRQIOCK2N3XBCPI6GESI5BYRD3D/
