mmap и Windows

заменить на malloc()

// wbr

> заменить на malloc()

:-) Так и сделаю...

Просто под Линуксом я наступаю на проблемы с фрагментацией, поэтому заюзал свои аллокаторы. Будем надеятся, под Виндой такого не будет.

может быть использовать VirtualAlloc, смотреть нужно.

// wbr

> может быть использовать VirtualAlloc, смотреть нужно.

Да, то, что надо. Thanks

> Просто под Линуксом я наступаю на проблемы с фрагментацией

Как это мешает пользовательскому приложению, и в чём ваш аллокатор превосходит malloc()?

Банально, но на всяк. случай, скажу: malloc при ошибке вернет NULL, а mmap - MAP_FAILED (== (void*)-1).

Что-то не очень понятно, какое отношение к фрагментации имеет факт, представленный вами.

> Что-то не очень понятно, какое отношение к фрагментации имеет факт, представленный вами.

жму на последнего:)

> Банально, но на всяк. случай, скажу: malloc при ошибке вернет NULL, а mmap - MAP_FAILED

Thanks, я в курсе! :-)

Это все много раз обсасывалось в учебниках, и на этом форуме обсуждалось, например, http://www.linux.org.ru/view-message.jsp?msgid=1454754

> Как это мешает пользовательскому приложению,

Фрагментацией памяти ;)

> и в чём ваш аллокатор превосходит malloc()?

Отсутствием фрагментации памяти (кто бы мог подумать!)

:-)

Хинт: они (мои аллокаторы), в отличие от malloc(), НЕ универсальные. Еще хинт: если я скажу mmap(), попользую память, а потом скажу ей munmap(), то фрагментации не будет вообще. Последний хинт: если я на каждый байт буду говорить mmap(), то это будет ОЧЕНЬ долго (поскольку через ядро, и память должна инициализироваться) и ОЧЕНЬ неэкономно (поскольку память маппится страницами).

> Это все много раз обсасывалось в учебниках

Признаюсь, ни в одном учебнике не встречал описания случая, когда бы пользовательскому
приложению понадобился собственный аллокатор

> Фрагментацией памяти ;)

Вопрос и был в том, чем фрагментация помешала приложению!

> Отсутствием фрагментации памяти (кто бы мог подумать!)

Слишком сильно сказано! Ни один из существующих аллокаторов полным отсутсвием фрагментации
похвастаться не может. Если ваш может, непременно запатентуйте его :-)

1) Вы замаппили несколько идущих не подряд страниц памяти, получили фрагментацию.

2) Замаппили несколько подряд идущих страниц, потом одна из страниц где-нибудь посередине
участка памяти оказалась не нужна,- размаппили, снова получили фрагментацию.

3) И наконец, как же это вам удалось-то от внутренней фрагментации избавиться? :-)

> Последний хинт: если я на каждый байт буду говорить mmap(),

Честно говоря, глубоко в коде маллока не копался, поэтому утверждать ничего
не буду, но сомневаюсь что он работает настолько примитивно.

> Признаюсь, ни в одном учебнике не встречал описания случая, когда бы пользовательскому приложению понадобился собственный аллокатор

А мы их пищем - только в путь. Просто в тех случаях, когда известна используемая дисциплина выделения/удаления памяти, выгоднее использовать собственный специализированный аллокатор в замен стандартному. Ну например, часто встречается дисциплина - выделяем много-много маленьких одинаковых фрагментов, а потом скопом все удаляем. Если написать специализированный аллокатор можно и фрагментацию уменьшить и затраты вычислительного ресурса на выделения памяти снизить.

граждане, что вы спорите на казалось бы пустом месте? це ж очевидно, что в частных случаях ручной аллокатор может быть весьма полезен. если к примеру приложение постоянно выделяет/освобождает достаточно большие массивы памяти (>> PAGE_SIZE), то вполне возможно, что делать это через mmap() действительно лучше, бо вызвав в конце munmap() приложение действительно возвращает память системе. что нельзя заранее сказать про вызов free() и как он себя поведёт.

естественно, что такое поведение платформозависимо, но нарисовать минимальную кроссплатформенную обёртку не составляет особого труда.

// wbr

ps: а фрагментируется память на уровне OS или не фрагментируется - это уже науке на известно и заведомо это не проблема приложения.

// wbr

CreateFileMapping с хэндлом -1 ?

> CreateFileMapping с хэндлом -1 ?

ну или так с хендлом INVALID_HANDLE_VALUE

// wbr

2Agent666: Я не открываю Америку; то, что я говорю -- давно и хорошо известные многократно обсосанные вещи. Например, классику можно почитать -- Кнута.

> Признаюсь, ни в одном учебнике не встречал описания случая, когда бы пользовательскому приложению понадобился собственный аллокатор

Ну, что я могу сказать... Читать надо больше! Можно по ссылке пройти, что я привел. Можно почитать новости про Огнелиса -- только что в троечку БСДшный аллокатор прикрутили, чтобы от фрагментации избавиться...

> Честно говоря, глубоко в коде маллока не копался, поэтому утверждать ничего не буду, но сомневаюсь что он работает настолько примитивно.

Мой хинт про mmap() на каждый байт относится к тому, что так просто взять и заменить malloc() на mmap() нельзя.

>2) Замаппили несколько подряд идущих страниц, потом одна из страниц где-нибудь посередине участка памяти оказалась не нужна,- размаппили, снова получили фрагментацию.

>3) И наконец, как же это вам удалось-то от внутренней фрагментации избавиться? :-)

Надо различать фрагментацию виртуального адресного пространства и физической памяти.

На фрагментацию виртуального пространства мне, в общем-то, пока наплевать: у меня 64-битная система. Но вот памяти всего 16 гиг, и malloc() их потихоньку фрагментирует, гад, за неделю в кашу разбивает, а мне надо гораздо дольше считать. Проблема с либсишным аллокатором известна: если конец свободного пула заткнут хотя бы байтом, остаток будет фрагментироваться (ибо эффективная дефрагментация возможна только железом, а для этого надо память отдать системе). Фрагментация в данном случае -- плата за скорость.

Отмапленные страницы не фрагментируются -- их физический порядок не важен (почти), трансляция адресов делается железякой.

Поэтому часто приходится писать свои аллокаторы. Обычно их даже не называют аллокаторами, поскольку они не универсальные и часто не оформлены в виде интерфейса наподобие malloc()/free(). Не обязательно они mmap() - базированные -- можно, например, зацепить большой кусок malloc()ом (в гнутой либси он все равно тогда mmapнется) и уже в нем устроить что-нибудь типа сборки мусора, а потом весь кусок освободить -- он вернется системе, поскольку был большим. Можно в стеке большой массив зацепить и в нем резвиться -- на выходе из функции память "освободится" (правда, системе не вернется).

> ps: а фрагментируется память на уровне OS или не фрагментируется - это уже науке на известно и заведомо это не проблема приложения.

:-)

Если бы память фрагментировалась на уровне OS, аптаймы не составляли бы более несколких дней...

Вдогонку к Die-Hard (18.03.2008 16:08:56):

> Поэтому часто приходится писать свои аллокаторы.

Разумеется, не только (и не столько) поэтому, наступить на проблему фрагментации довольно трудно. Основной причиной является повышение производительности ad hoc аллокаторов, как пояснил Burbaka (18.03.2008 10:27:08).

> Надо различать фрагментацию виртуального адресного пространства и физической памяти.

То, что вы называете "фрагментацией физической памяти", на самом деле называется
"внутренняя фрагментация". Вот если бы вы сразу написали, что ваш аллокатор (подозреваю что это что-то
вроде сляб-аллокатора) уменьшает внутреннюю фрагментацию, я бы сразу вас понял. Но и в этом случае
вы не можете на СТО ПРОЦЕНТОВ (ваше "отсутствием фрагментации" не совсем корректно) от неё
избавиться, можете только уменьшить. Полносьтю избавиться можно, только если суммарный размер
N-ого количества страниц кратен размеру выделяемой структуры.

>Признаюсь, ни в одном учебнике не встречал описания случая, когда бы пользовательскому приложению понадобился собственный аллокатор

в реальной жизни встречается довольно часто. Из примеров: doom, quake, Firefox/jemalloc, сервера приложений и т.п.

2Agent666:

:-) "Волны перекатывались через мол и падали вниз стремительным домкратом"... А я еще разжевывал, вместо того, чтобы просто сказать RTFM!

Мне разжёвывать это не нужно, это я и так неплохо знаю. Я всего лишь навсего поинтересовался,
почему вашему приложению так критична фрагментация. Не думаю, что TFM содержит ответ
на этот вопрос.

P.S. Всё, тема на этом закрыта.

2Agent666:

Уважаемый, из Вашего (пред)последнего поста понятно, что Вы под аллокатором понимаете способ, которым ядро запрашивает у процессора память. Какое отношение это имеет к дискуссии вообще и к malloc() в частности, а также к Вашим начальным вопросам?

> Уважаемый, из Вашего (пред)последнего поста понятно, что Вы под аллокатором понимаете способ, которым ядро запрашивает у процессора память.

Приведите мне ту мою цитату, которая Вас привела к этому нелепому выводу.

> Приведите мне ту мою цитату, которая Вас привела к этому нелепому выводу.

> То, что вы называете "фрагментацией физической памяти", на самом деле называется "внутренняя фрагментация". Вот если бы вы сразу написали, что ваш аллокатор (подозреваю что это что-то вроде сляб-аллокатора) уменьшает внутреннюю фрагментацию, ...

Весь этот жаргон типичен для разработчиков ядра и файловых систем (cache, slab and buddy memory allocation, internal and external memory fragmentation). На юзерспейсе обычно интересует лишь наличие свободной памяти. Естественно, что фрагментация отожранного пула может быть только "внутренней", это ж не файловай система и не ядро!

А вот еще:

> Полносьтю избавиться можно, только если суммарный размер N-ого количества страниц кратен размеру выделяемой структуры.

На юзерспейсе полностью избавиться от фрагментации можно гораздо проще: отдаю всю ненужную память системе, и -- аля-улю! Никакой фрагментации :-)

> отдаю всю ненужную память

Тогда уж просто - отдаю всю память системе :)

> Весь этот жаргон типичен для разработчиков ядра и файловых систем ... lab and buddy memory allocation,

А что юзерспейсный malloc чем-то принципияльно отличается? ;)

> А что юзерспейсный malloc чем-то принципияльно отличается? ;)

да что уж там мелочиться.. Файловая система -- это тоже всего навсего malloc дисковых секторов..

> Тогда уж просто - отдаю всю память системе :)

Шутки -- шутками, но иногда так и приходится поступать.

Коллега наступил на грабли с фрагментацией, когда что-либо делать уже поздно было (легче программу всю с нуля было переписать). Хорошо, что у него были чекпоинты. Пришлось делать так: раз в несколько дней вырубать программу и восстанавливаться с чекпоинта.

Вообще, стандартному сишному менеджеру памяти не достает одной важной фичи: возможности создания нескольких независимых куч. Очень часто на различных этапах работы требуется временно делать много потенциально фрагментирующих операций, а потом все это становится мусором, который можно скопом освободить. В принципе, с ГНУтым маллоком это можно сэмулировать, но только если стартовый объем достаточно велик, чтобы оно ммапнулось. Но это и будет "написанием своего аллокатора", к тому же универсального...

> А что юзерспейсный malloc чем-то принципияльно отличается? ;)

Ну да, особенно актуальна для юзерспейсного маллока внешняя фрагментация и продвинутые алгоритмы дефрагментации ;)

Да и понятие внутренней фрагментации для юзерспейса не совсем корректно, поскольку страницы фактически не видны. Разве что в контексте выравнивания на границу слова...