real-time garbage collector

я считаю GC и real-time несовместимыми вещами...

Ну и зря

Хорошо, мне нужно выделять/уничтожать 2-6Кb блоки, порядка 500-600 раз в секунду, с гарантированым временем отклика <=50ms.

Боюсь дефрагментации памяти, поэтому спрашиваю про GC. Cамописный аллокатор не подходит.

> Боюсь дефрагментации памяти, поэтому спрашиваю про GC

Э ... фрагментации, да?

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

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

конечно - 'фрагментации' (думал про нее, но написал автоматом с 'де') :)

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

А как начет этого:

The Boehm-Demers-Weiser conservative garbage collector can be used as a garbage collecting replacement for C malloc or C++ new. It allows you to allocate memory basically as you normally would, without explicitly deallocating memory that is no longer useful. The collector automatically recycles memory when it determines that it can no longer be otherwise accessed.

> А как начет этого

В каком смысле? В приведенной цитате описано, что такое GC. Про [де]фрагментацию ничего не сказано.

Я ж не утверждал, что GC для Си невозможен - я высказывал соображение, что помочь в борьбе с фрагментацией памяти он не сможет, т.е. фрагментации будет не меньше чем при правильном использовании обычных аллокаторов.

Соображение, впрочем, дилетантское, и буду признателен за комментарии более компетентных участников конференции.

> Я ж не утверждал, что GC для Си невозможен - я высказывал соображение, что помочь в борьбе с фрагментацией памяти он не сможет, т.е. фрагментации будет не меньше чем при правильном использовании обычных аллокаторов.

да действительно, с фрагментацией он помочь никак не сможет, но вопрос-то был в другом:

> существуют ли юзабельные open-source real-time garbage-collector'ы для C++ применяемые в практике?

ну гугл в помощь, наверняка есть, бо ещё в 94 году была изложена основная концепция http://portal.acm.org/citation.cfm?id=198017.198022&dl=GUIDE&dl=GUIDE...

Скорее всего ты даже не представляеш что такое GC и зачем его изобрели

начни с того что пересмотри архитектуру приложения. Может тебя вполне устроит статический массив?

а вообщето специально для тебя придумали obstack. Во первый быстрый. На порядки быстрее malloc(). Во вторых приняты более серьёзные меры для предовращения фрагментации...

а вообщето: Боишся фрагментации - пользуй стек :-)

и посмотри в строну alloca() и компании. Не уверен но вдруг пригодится

на самом деле даже dlalloc подойдёт, бо его можно очень хорошо заточить под конкретное приложение,

s/dlalloc/dlmalloc/

>Хорошо, мне нужно выделять/уничтожать 2-6Кb блоки, порядка 500-600 раз в секунду, с гарантированным временем отклика <=50ms. Боюсь дефрагментации памяти, поэтому спрашиваю про GC. Cамописный аллокатор не подходит.

А можно ли просто выделять/уничтожать блоки фиксированного размера (например, 8 килобайт)? Тогда фрагментации можно, наверное, избежать; по крайней мере, самопальный аллокатор будет проще.

> Cамописный аллокатор не подходит.

Если жесткий релтайм, то именно "самописный аллокатор" (aka GC) и может оказаться лучшим выбором, но для этого требуется мастерство высокого уровня. Ведь скорее всего, нужен не GC общего назначения, а нечто узко-специализированное под конкретную задачу. Так? Здесь даже проблема больше не в программировании, а в правильной постановке задачи. Но если нет уверенности, то тогда лучше имхо искать другие пути решения.

З.Ы. Успешный опыт написания собственного GC был, но там никакой не real-time. К тому же этот GC заточен исключительно под одну задачу, где стандартный дот-нетовский GC оказался совершенно не удел в силу определенных причин... :)

То есть, мой пойнт состоит в том, что GC вроде Boehm-Demers-Weiser решает общую задачу, которая может быть избыточной для частного случая, но такое решение часто оказывается вполне приемлимым и допустимым для обычного десктопа. Может быть, в вашем частном случае многое можно упростить, и обойтись без таких ненужных жертв как монструозный GC общего назначения. Другими словами, я бы советовал пересмотреть постановку задачи.

Может быть стоит подумать о применении другого языка? erlang например обладает сборщиком мусора, и в то же время позволяет писать real-time код.

Почему не использовать стек? Все вменяемые компиляторы поддерживают C99, а C99 это массивы на стеке динамического размера. 6 KiB это не так много , имхо. Ввремя жизни этих блоков, как я понимаю, не слишком большое?

+1, я тоже сразу об Эрланге подумал.

гугл показавaет те же ссылки :(

> Скорее всего ты даже не представляеш что такое GC и зачем его изобрели

может быть

> начни с того что пересмотри архитектуру приложения. Может тебя вполне устроит статический массив?

думаю об этом

> а вообщето специально для тебя придумали obstack. Во первый быстрый. На порядки быстрее malloc(). Во вторых приняты более серьёзные меры для предовращения фрагментации...

это фича только GNU libc? нужна поддержка win32 тоже.

> а вообщето: Боишся фрагментации - пользуй стек :-)

не получится. Все события извлекаются из очереди сообшений (много каналов на одну очередь, каждый канал это FSM), события могут приходить из внешнего источника (eg. IP сеть) или железа (ISDN, SS7, playback functions). В данныи момент на каждое событие выделяется кусок памяти (в heap), туда запихиваются данные и указатель на етот кусок помешается в очередь, потом извлекается аддресованным каналом, обрабатывается/уничтожается. эта модель работает и вроде бы все без проблем, но что-то мне подсказывает, что могут быть проблемы с фрагментацией памяти при долгой работе.

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

Да, знаю, Erlang сюда напрашивается, сам хотел бы его использовать, но привязка Erlang к железу (все API на C) используя ports, или linked-drivers очень ненадежна. Если упадет driver, он потащит за собои Erlang's VM.

> Все события извлекаются из очереди сообшений (много каналов на одну очередь, каждый канал это FSM), события могут приходить из внешнего источника (eg. IP сеть) или железа (ISDN, SS7, playback functions). В данныи момент на каждое событие выделяется кусок памяти (в heap), туда запихиваются данные и указатель на етот кусок помешается в очередь, потом извлекается аддресованным каналом, обрабатывается/уничтожается. эта модель работает и вроде бы все без проблем, но что-то мне подсказывает, что могут быть проблемы с фрагментацией памяти при долгой работе

Описанная ситуация сама по себе абсолютно нормальна. Советую провести стресс-тестирование, чтобы понять, есть ли основания для беспокойства. Если есть, то смотреть в сторону подбора аллокатора и/или его настроек, в сторону унификации размера блоков памяти. Если запросы как-то взаимозависимы, то можно поиспользовать obstack.

Ну и, естественно, memory leak'ов быть не должно.

GC здесь не к месту.

это уже работает в production (Solaris/sparc64 i Linux/x86) :) проблем пока не видно.

но использoвание heap в таком виде меня тревожит...

> это уже работает в production (Solaris/sparc64 i Linux/x86) :) проблем пока не видно.

Стресс тестирование потому и стресс, что создает бОльшую нагрузку, чем бывает в production. В твоем случае оно должно сопровождаться внятными средствами диагностики (когда какие куски освобождались, какая была фрагментация), потому что простого упало/не упало или простого наблюдения за занимаемой памятью будет мало.

У valgrind есть некий tool под названием massif. Попробуй на него посмотреть.

> но использoвание heap в таком виде меня тревожит...

Ты хочешь поговорить об этом?

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

Ну ладно, успокоили :)

Всем участникам спасибо за рекомендации.

> Хорошо, мне нужно выделять/уничтожать 2-6Кb блоки, порядка 500-600 раз в секунду, с гарантированым временем отклика <=50ms.

Если размер выделяемого блока у тебя в 1-2 страницы - то сильно беспокоиться о фрагментации памяти тебе не нужно, даже с т.з. производительности.

Ну и, если верить твоему описанию, ты можешь не напрягаясь перейти на 8к (выровненные двухстраничные на x86, да и на sparc, вроде, так же) блоки постоянного размера, после чего задача написания быстрого (O(1)) pool-аллокатора становится тривиальной. Почему ты считаешь, что

> Cамописный аллокатор не подходит

?