Комментарии 5
Каким образом предлагается эффективно реализовать owns(), если потребовалось выделить несколько блоков? Насколько я понял предложенный дизайн, этим должен заниматься Cascading - и как раз про него сказана только пара слов ("Однако его реализация является не самой тривиальной из-за сложной логики поведения") - получается, обрывается на самом интересном...
Не будет ли из-за owns() просадки по производительности, если придётся насоздавать много блоков и, соответственно, аллокаторов?
И ещё как реализовать owns(), если мы хотим такой аллокатор, который, скажем, будет вызывать mmap для больших аллокаций. Ведь адреса, возвращаемые mmap, непредсказуемые, в том смысле, что range-проверки недостаточно.
Да, есть некоторые проблемы с производительностью owns при выделении нескольких блоков. Возможно, есть какие-то оптимизации, но мне про них не известно.
По поводу mmap. Я, честно говоря, не знаю специфики этого метода, потому не очень понял проблему(не он ли лежит под malloc/new в linux? если так, то не понял проблему ещё больше, ведь c malloc/new таких вопросов не возникает). На мой обывательский взгляд кажется, что он всё ещё вернёт мне какой-то блок, с границами которого и можно делать range-test. Или я всё-таки что-то упускаю? Если это не так, то да, могут возникнуть проблемы при реализации owns. Как это сделать эффективно в случае случайности адресов, не очень понятно.
Про mmap я имел в виду, что если аллокатор не делает низкоуровневого управления памяти, а просто вызывает mmap, то в ответ от mmap он будет получать какие-то адреса в случайных местах в памяти. Тогда для реализации owns() аллокатору придётся держать какую-то вспомогательную структуру данных, в которой будут храниться все выделенные через него адреса. Что выглядит как ещё одна большая проблема в предложенной архитектуре...
Вот блин. Не посмотрев, что это перевод, прочитал два экрана, подумал "Что-александресковщина какая-то", дочитал - вернулся в начачло: ага, реально Александреску!
Базовые концепции аллокаторов