информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Сетевые кракеры и правда о деле ЛевинаВсе любят медСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[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-блоках

но повторю - это извращения - юзай связанные списки - скорости у них хватит ...
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach