Дефрагментация C ++ Heap Allocator & STL
Инструментарий GC IBM делает точно, что Вы спрашиваете.
https://www.ibm.com/developerworks/java/jdk/tools/gcmv /
я не уверен, совместимо ли это с журналами GC от JVM Sun все же.
5 ответов
Если вы собираетесь перемещать объекты в памяти, вы не можете этого сделать. полностью в целом. Вы сможете сделать это только с объектами, которые знают , что они могут быть перемещены. Также вам понадобится запорный механизм. Когда функция вызывается для объекта, ее нельзя переместить.
Причина в том, что вся модель C ++ полагается на объекты, находящиеся в фиксированных точках памяти, поэтому, если поток вызывал метод объекта , этот поток был приостановлен и объект перемещен, при возобновлении потока произойдет сбой.
Любой объект, содержащий необработанный указатель памяти на другой объект, который может быть перемещен (включая его подобъект), не будет работать.
Такая схема управления памятью может работать, но вы должны быть очень осторожны. Вы должны быть строги в отношении реализации дескрипторов и семантики блокировки дескрипторов-> указателей.
Для контейнеров STL вы можете настроить распределитель, но он по-прежнему должен возвращать фиксированные необработанные указатели памяти. Вы не можете вернуть адрес, который может переехать. По этой причине, если вы используете контейнеры STL, они должны быть контейнерами дескрипторов, а сами узлы будут обычной динамически выделяемой памятью. Вы можете обнаружить, что у вас слишком много накладных расходов при косвенном обращении к дескрипторам, и все еще есть проблемы с фрагментацией коллекций дескрипторов, чем вы получаете с помощью STL.
Использование контейнеров, которые понимают ваши дескрипторы напрямую, может быть единственным путем вперед,
Контейнеры STL реализованы с использованием голых указателей.
Вы можете указать настраиваемый распределитель при их создании (чтобы они инициализировали свои указатели с помощью вашего распределителя), но (поскольку выделенные значения являются хранятся в голых указателях) вы не знаете, где находятся эти указатели, и поэтому не можете изменить их позже.
Вместо этого вы можете подумать о реализации подмножества STL самостоятельно: ваши версии контейнеров STL могут быть реализовано с управляемыми указателями.
Альтернативная методика, которая довольно хорошо известна, - это система друзей . Вам следует взглянуть на это, чтобы получить дополнительное вдохновение.
Если это предназначено для программирования консольных игр, гораздо проще запретить выделение динамической памяти без ограничения во время выполнения. И во время запуска, но этого немного сложно добиться.
Я считаю, что если нужно бояться фрагментации, это означает, что вы жонглируете с частями данных, которые составляют огромную часть вашей памяти, и только благодаря этому достоинству у вас не может быть их много. Вы уже знаете, что это будет? Может быть, было бы лучше перейти на следующий уровень и принять более конкретные решения, тем самым меньше влияя на другой код и общую производительность вашего приложения?
Список является исключительно плохим примером для использования в диспетчере дефрагментации памяти, потому что это набор крошечных кусочков, как и большинство других структур данных STL. Если вы сделаете это, это будет иметь все виды очевидных плохих последствий - включая снижение производительности вашего дефрагментатора, а также стоимость косвенного обращения и т. Д. Единственные структуры, в которых имеет смысл ИМО, - это серьезные - массив, двухсторонняя очередь, основной блок хеш-таблицы, все те вещи, и только за пределами определенного размера, и только после того, как они больше не будут изменять размер. Подобные вещи, опять же, требуют конкретных решений, а не общих.
Прокомментируйте, как все это получается.