On Thu, 6 Jun 2019 13:57:37 -0500 Tim Peters <tim.pet...@gmail.com> wrote: > [Antoine Pitrou <solip...@pitrou.net>] > > The interesting thing here is that in many situations, the size is > > known up front when deallocating - it is simply not communicated to the > > deallocator because the traditional free() API takes a sole pointer, > > not a size. But CPython could communicate that size easily if we > > would like to change the deallocation API. Then there's no bother > > looking up the allocated size in sophisticated lookup structures. > > That could work (to make it possible to increase obmalloc's pool > size). Except ... > > > I'll note that jemalloc provides such APIs: > > http://jemalloc.net/jemalloc.3.html > > > > """The dallocx() function causes the memory referenced by ptr to be > > made available for future allocations. > > > > The sdallocx() function is an extension of dallocx() with a size > > parameter to allow the caller to pass in the allocation size as an > > optimization.""" > > obmalloc doesn't intend to be a general-purpose allocator - it only > aims at optimizing "small" allocations, punting to the system for > everything beyond that.
But my response was under the assumption that we would want obmalloc to deal with all allocations. 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. 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/
