Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Memory Manager - контроль кучи, алгоритм. Что скажете? 18.06.01 17:55 Число просмотров: 1086
Автор: XR <eXtremal Research> Статус: The Elderman
Отредактировано 18.06.01 18:03 Количество правок: 1
|
> привет всем.
[skip]
>
> иначе говоря - сначала резервируем вольшой кусок памяти -
> куча, скажем на 8Kb - HEAP. теперь, вызываем new и пытаемся
> получить пространство размером в 256 байт -Block. в
> операторе new, перенаправляеться на MemManager.
> MemManager ищет внутри 8Kb (HEAP) свободное место, помечает
> его как используемое, помечает используемый размер (256),
> если нужно делает пометки, для внутреннего использования и
> возвращает указатель на начало блока (Block). т.е. каждый
> HEAP содержит внутри n-ое кол-во Block.
>
> при освобождении, т.е. вызов - delete Block, смотрит из
> какой кучи (HEAP) он выдавал Block, помечает Blockкак
> свободный, или происходит слияние этого блока с
> предидущим/последуюущим если они тоже помечены как
> свободный. естественно увеличивая размер свободного
> пространства + 256.
>
> теперь вопрос. естественно как то надо вести учет
> свободного простраиства, и держать информацию о всех
> блоках. есть вариант всю инфу собирать и контролировать
> через связанные списки, не трудный вариант, но он плох тем
> что на поиск блока внутри кучи тратиться время и не малое.
>
> у кого будут другие предложения, может кто занимался
> подобным?
>
> и еще. будь он связанный список или еще какой объект, он
> должен быть внутренний. и вызов операвтора new не разрешен,
> т.к. пойдет рекурсия - MemManager сам конролирует new /
> delete.
>
> не знаю на сколько понятно все изложил, думаю те кто писали
> подобное поняли о чем речь. а если кто не понял,
> спрашивайте, не стесняйтесь :-)))
Пара замечаний:
1)Ты видимо решил отказаться от весьма удобной привязки памяти к страницам с
аппаратной поддержкой функции защиты страниц,и сделать т.н. "общий случай"
т.е. ты в случае BOF легко сможешь разрушить всю внутреннюю структуру своего
хипа - я в аналогичной ситуации привязывался таки к страницам и заголовки
блоков держал в защищеных от записи страницах (mprotect() -ом) что по крайней мере гарантировало целостность внутренней структуры а заголовки блоков разблокировались только при операциях выделении/освобождении памяти - минус такого подхода это минимальный размер блока в 8кв
2) c точки зрения скорости двунаправленного связянного списка сейчас хватает за
глаза ... а вот с точки зрения оптимизации фрагментации удобнее деревья
(оптимальный поиск подходящего блока и простота слияния 2-х соседних своботных)
По идее ты просто строишь 2-дерева на одном наборе блоков одно использует как ключ размер блока и используется для оптимального выделения памяти второе использует в качестве ключа адрес блока и используется для оптимизации
слияния блоков при освобождении памяти
то есть ты хранишь 2-набора указателей и любая операция с памятью будет приводить к изменениям в 5-блоках
но повторю - это извращения - юзай связанные списки - скорости у них хватит ...
|
|
|
подробно о проекте
Анализ криптографических сетевых...
