On Fri, 21 Jun 2019 17:18:18 -0500 Tim Peters <tim.pet...@gmail.com> wrote: > > > And what would be an efficient way of detecting allocations punted to > > malloc, if not address_in_range? > > _The_ most efficient way is the one almost all allocators used long > ago: use some "hidden" bits right before the address returned to the > user to store info about the block being returned.
There's a fundamental problem here: you can't be sure that all allocators reserve such space. If some allocator doesn't, it can return a pointer just at the very start of the page, and if obmalloc tries to look at "a few bits before" that address, it could very well page-fault. > Neil Schemenauer takes a different approach in the recent "radix tree > arena map for obmalloc" thread here. We exchanged ideas on that until > it got to the point that the tree levels only need to trace out > prefixes of obmalloc arena addresses. That is, the new space burden > of the radix tree appears quite reasonably small. One open question is the cache efficiency of the two approaches. Intuitively, address_in_range() will often look at exactly the same cache line (since a significant number of allocation will share the same "page prefix"). Apparently, this benefit may be offset by cache aliasing issues. Cache aliasing can also be mitigated by the fact that CPU caches are most of the time N-way with N > 1 (but N generally remains small, from 2 to 8, for L1 and L2 caches). So I guess the a priori answer is "it's complicated" :-) I must also thank both you and Neil for running these experiments, even though sometimes I may disagree about the conclusions :-) Regards Antoine. _______________________________________________ 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/RUQVG2KOYVMUIIX5HIZKNVN4AUXKKURM/
