Вячеслав Егоров mraleph

ну вы просто поджигаете... во-первых, я не совсем понимаю почему вы всё время называете сборщик --- аллокатором, безусловно стратегии аллокации и сборки связанны, но это совсем не одно и тоже. особенно меня поражает "generational аллокатор", это что еще за зверь такой? Сборщики бывают поколенными, это да... Но поколенный аллокатор я слабо себе представляю. Конечно, можно сделать некоторые эвристические предположения или анализ (ключевые слова: prolific types, CBGC) и иногда при выделении памяти сразу выделять память и старого поколения (JVM так поступает для очень больших объектов).

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

Вообщем и целом у меня создаётся впечатление, что вы пытаетесь рассуждать о вещах, о которых имеете лишь поверхностное представление.

читал я сию статью, безусловно познавательно, как и большинство статей бородатого дяди Хертца. Но вообще не показатель --- там же с оракулярным управлением сравнивается, а оракул он всегда знает лучшую точку, в которой можно удалить объект... Но что самое забавное в заключении там сказано: Comparing runtime, space consumption, and virtual memory footprints over a range of benchmarks, we show that the runtime performance of the best-performing garbage collector is competitive with explicit memory management when given enough memory.

чего-то я не понял, причем тут переключение контекстов. не поясните ли?

и я вам говорю, можно убрать барьеры на запись в некоторых случаях. Почитайте например статьи дяди Detlefs'а (например, Compile-time concurrent marking write barrier removal).

жжоте, неудачный у вас примерчик... уже то, что вам надо входить в критическую секцию аукнется на любой более менее активно аллоцирующей в нескольких потоках программе. ну это ладно.
вы можете мне объяснить что мешает скажем Java программе делать почти тоже самое --- найти блок подходящего размера и отдать его программе?
Оставим в стороне счетчик ссылок, но даже glibc дополнительно к запрошенному куску памяти выделаяет еще место под заголовок. Так что оверхеда никакого особого нет. Вообщем никаких доказательств того, что аллокаторы в неуправляемых средах будут работать быстрее я пока так и не увидел.

Теперь что касается удаления. Да, даже при применении различных ухищрений (различные виды incremental/concurrent collection) эта операция дольше чем просто вызов delete/free/VirtualFreeEx. Однако это замедление в общем случае не настолько значительное, чтобы городить велосипед ручного управления памятью. Написать нормальный ручной аллокатор/деаллокатор фактически означает переписать некоторую часть среды управления памятью из какой-нибудь VM. Ну и нафиг это нужно среднестатистическому программисту?

Ась? Вы так и не ответили на мой вопрос... Почему аллокация-то разгонятся... Нету в вашем комментарии слов "аллокация"/"выделение", а есть куча общих слов о том, что GC --- это бяка. Насколько я понял, вы про read/write барьеры говорите. Так ведь некоторое их количество и поудалять можно на основе статического анализа.
На практике мы всё имеем: и специальные компиляторы и особое железо (Azul Systems).

Язык без указателей и при этом не тормозящий в мутьтитредной среде - это как философский камень.

Кхе-кхе, чего-то я не особо секу как наличие указателей ускоряет собственно аллокацию. Не поясните ли? (если же поговорить о распараллеливание, так как раз из-за указателей и проблемы вылезут. зависимость по данным отследить --- это надо пуд соли съесть.)
Если говорить об ускорении аллокации, то Thread Local Heap'ы пока никто не отменял.

Но на сервере из-за нее происходит трешинг кэшей процессора и задержки в обработке запросов (во время обхода кучи сборщиком мусора).

Во-первых, кеши все больше и больше. Во-вторых, седовласые старцы тоже не зря свои бутерброды кушают и изобретают различные подходы к GC позволяющие кэшем меньше шебуршать, да и вообще всякие real-time GC. Ну и наконец, есть всякие железные ухищрения, см. например Azul Systems.

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

Точно также вы можете забыть ссылку и в программе на С, а можете даже не просто забыть, а потерять. И придётся изучать те же самые дампы.

В языках с GC вы можете попросить runtime дать вам дамп кучи. А потом методом внимательного взгляда понять что к чему.
Скажем так, те ошибки, на которые вы указываете для языков с автоматическим управлением памятью, точно также свойственны и языкам с явным управлением: потеряли вы в C указатель и привет семье (причем заметим, что к segfault это не приведёт, просто ресурсы "утекать" начнут, так что не обязательно во время тестирования выявится), нужно расчехлять valgrind или efence, причем может так оказаться, что развертывать это отладочное окружение нужно будет на стороне клиента. А в некоторых управляемых средах вам и развертывать ничего не надо: цепляетесь к запущенному под VM приложению по официальному отладочному интерфейсу и начинаете шукать по сусекам, где чего лишнего осталось.
С другой стороны нельзя не признать, что например C++ благодаря автоматическому вызову деструкторов для стековых объектов делает возможным написание очень красивого кода для управления ресурсами (RAII --- Resource Acquisition Is Initialization), в той же Java приходится во все дырки finally затыкать.

а ежели у вас segfault случается раз в двести лет, когда звезды в ряд становится и древнее зло просыпается?
вот возьмёт и у вас во время тестирования не вылезет, а к клиенту отправите --- порвёт все на кусочки...