[Antoine Pitrou <solip...@pitrou.net>]
> But my response was under the assumption that we would want obmalloc to
> deal with all allocations.
I didn't know that. I personally have no interest in that: if we
want an all-purpose allocator, there are several already to choose
from. There's no reason to imagine we could write a better one.
> Which is more or less required anyway to have an efficient GC that doesn't
> have to walk linked lists and access memory in random order to iterate over
> known objects.
As the parent thread showed, obmalloc does at least as well as any
general-purpose allocator known _for Python's purposes_ (a great many
(de)allocations of "small" objects). Already explained too that
size-segregated linked free lists are the core of _why_ it does so
well. Besides making carving off, and freeing, blocks dirt cheap,
linked lists also naturally support recycling memory blocks in MRU
("freshness in cache") order.
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. Over on
Discourse, Neil is speculating about using radix trees for cyclic gc
instead of _its_ linked lists In obmalloc, allocated memory regions
aren't linked at all. It's free regions that are linked, and
helpfully so in MRU order.
_______________________________________________
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/
