Некоторые новшевства в glibc 2.10

Спасибо за линк.

> хак printf

Hook не хак.

>Hook не хак.

да, виноват.

>Некоторые новшевства

Прочитал: некоторые вещества

Теперь glibc умеет отдавать статистику по malloc в формате XML. Сердце мое трепещет :D

*посыпает голову пеплом и пинает спелчекер* ><

Отлично! Побольше бы таких новостей на лоре :)

C++ 0x стал C++ 201x? Фигово однако... =(

надеюсь тпереь ГНУтый аллокатор памяти будет нормально работать с фуррифоксом. не надо будет плясать с бубном.

>C++ 0x стал C++ 201x? Фигово однако... =( Главное чтобы последний 'x' не превратился в девятку...

Так будет там нормальный менеджер памяти или так и будет каждое приложение свой писать? ;-)

сначало подумал о Metallica, выздоравливаю?

Что по вашему нормальный? Потребности у всех разные, если всё впихивать в glibc это знаетели - просто ужас выйдет. А качество как видно повышается, и фичастость увеличивается, стало быть он становится нормальным:) А в реальности разные потребности у людей, совсем разные, так что писать свой кто-то всё равно будет. У меня вот была потребность сделать аналог malloc, но чтобы куча была просто некоторым буфером, а выделяемые участки адресовались не указателями, а индексами. Чтобы буферы можно было сбрасывать в файлы. Ну сделал, но не дай бог подобные или что-либо другое появится в glibc.

> Что по вашему нормальный?

Х.З. Но за время религиозный войн OOo и Firefox менеджер памяти из glibc не обругал только ленивый.

Ясно, ну это ровным счётом ничего не значит:) Если кому-то было бы действительно нужно, чтобы аллокер glibc работал иначе, за ним бы не заржавело добавить "правильную реализацию":)

>новшевства

эээ... исправьте что-ли в заголовке...

По теме - у Ульриха куча полезных и интересных для разработчиков статей на сайте.

>Теперь glibc умеет отдавать статистику по malloc в формате XML
Можно начинать похоронную процессию?

Зря вы так, мерить потребление и утечки в реальном времени это весьма важно. Другое дело, что для этого можно более удобные механизмы использовать:) Но всё равно это хорошо.

>Зря вы так, мерить потребление и утечки в реальном времени это весьма важно.
Да я не говорю, что это не нужно. Просто XML уж _здесь_ ну точно совершенно не к месту.

Эх, дань моде и стандартизации. Вот скажем зачем в dbus интроспекция не в idl, а на xml ? И тут тоже самое, остаётся лиш смириться:)

> Да я не говорю, что это не нужно. Просто XML уж _здесь_ ну точно совершенно не к месту.

А Вы по ссылке ходили? С учетом постановки задачи, XML, похоже, наиболее адекватное решение.

>надеюсь тпереь ГНУтый аллокатор памяти будет нормально работать с фуррифоксом. не надо будет плясать с бубном.

Ламеры типа тебя будут плясать ВСЕГДА

>Но за время религиозный войн OOo и Firefox менеджер памяти из glibc не обругал только ленивый ЛАМЕР.

fixed

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

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

А ff может и все 4 гига скушать после недельной работы.

не замечено. 2 дня аптайм фф, 1 гиг рам, 500 мб занято всего вместе с гномом.

Я его могу и за 10 минут в свап загнать. И что?

У меня он вообще неделями на работе не вырубается. И ничего, нормально.

> А ff может и все 4 гига скушать после недельной работы.

300 метров сожрал
аптайм 8 days, 18:43
ФФ не перегружал, мля буду!

Это поведение, естественно, зависит от сайтов, которые смотришь. На тяжелых сайтах с обилием java script'а очень часто он вылезает за гигабайт физической памяти (!), потом закрытие вкладок не помогает, помогает только перезапуск.

да, да, именно так. особенно если вкладок много.

Там, кажется, еще через флеш-плагин может утекать. А так да, если кроме лора никуда не ходить, можно годами не перезапускать.

прикол в том, что флеш-плагин, как и все другие плагины, отрублены напрочь. но память пропадает всё равно. хотя х.з., может на других дистрах это и не так, у меня убунта на обеих машинах - на одной xubuntu, на другой linux mint.

Подскажу. Написать код для xpcom, который будет отслеживать все выделения памяти и давать статистику утечек, а также давать информацию о потребляемой памяти в реальном времени. Для наиболее чёткого учёта потребления и утечек, нужно везде, где память выделяется, маркировать это явным образом. Так, чтобы отслеживающий код показывал маркеры. Вот тогда буде всё ясно. Какой компонент, при каких условиях и почему потребляет память или банально течёт. И это никоим образом не входит в задачи аллокера, это задача грамотного кода или прослоек. Так что это притензии к мозилле:) PS: все кто сейчас случайно или неслучайно вспомнят про gc и посетуют на то, что он редко используется проектами на С или на С++ - строем идут в биореактор.

> се кто сейчас случайно или неслучайно вспомнят про gc и посетуют на то, что он редко используется проектами на С или на С++ - строем идут в биореактор.

Обоснуй или идешь ты.

Что я должен обосновать? Зачем людям нужна свобода ? Думаю это давно уже обосновано.

Прочитайте ещё раз мою фразу и поймёте что там написано.

Ну а если требуется пояснение, попытаюсь:)

Так вот, сборщик мусора не является заменой грамотного явного выделения и освобождения памяти, а является решением, которое можно использовать вместо или вместе с явным выделением/высвобождением. Грамотное же выделение и освобождение памяти(а желательно с механизмами отслеживания что где и когда выделялось) не может работать хуже, чем сборщик мусора, так как утечки, задержки и прочие проблемы - исключены.

Мозилловцы как и многие другие, демонстрируют своё не слишком дотошное отношение к ресурсам, отсюда и такие проблемы.

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

Под вечер прочитал как "Некоторые вещества в glibc 2.10"...

> Теперь glibc умеет отдавать статистику по malloc в формате XML

А почему не в pdf или odt?

.docx же

> У меня вот была потребность сделать аналог malloc, но чтобы куча была просто некоторым буфером, а выделяемые участки адресовались не указателями, а индексами. Чтобы буферы можно было сбрасывать в файлы. Ну сделал, но не дай бог подобные или что-либо другое появится в glibc.

Хе-хе, "арена" ?:) Вот тут сравнительно неплохая рассказка и подборка линков на "нестандартные аллокаторы" http://en.wikipedia.org/wiki/Dynamic_memory_allocation

жив курилка

Да нет, там была несколько более сложная реализация. которая позволяла в том числе объединять свободные куски, находящиеся в разных частях кучи. То есть делать дефрагметацию. При этом индексы тоже изменялись, так как в этом буфере всё и хранилось. Правда в силу специфических потребностей так и недовёл аллокер до того состояния, которое бы позволяло его использовать в других проектах:) Дефрагметация работала только с соблюдением чётких правил и тд и тп.

А воообще, я лиш хотел упомянуть, что разные проекты, по разному работающие с памятью, требуют разных подходов к выделению и отслеживанию памяти. Хотя крикуны продолжают кричать про дешевезну памяти, всё же неправильно написаный код съест всю память и неподавится. Жаль что программисты не уделяют достаточно внимания работе с ресурсами.

> сборщик мусора **не является заменой** грамотного явного выделения и освобождения памяти, а является решением, которое можно использовать **вместо** или вместе с явным выделением/высвобождением.

Сам-то понял, чё пёрнул?

СМ - это более продвинутый механизм работы с памятью, прекрасно работающий для 99% приложений. Он не просто "сам всё собирает", но и меняет саму концепцию работы с памятью - упрощает вплоть до "дай мне кусок, потом делай с ним что хошь". Экономит В РАЗЫ время на отладку, опережая "грамотных" чудиков-распределяльщиков. В результате, даже у не самых продвинутых прогеров улучшается код, полностью исключая ошибки тупого дизайна Си-еблибатеки.

> На тяжелых сайтах с обилием java script'а очень часто он вылезает за гигабайт физической памяти (!),
Вот-вот. На n810 у меня висит весь такой вебдванольный гмыл, денек повисит - и уже вся память сожрана...

> Хотя крикуны продолжают кричать про дешевезну памяти, всё же неправильно написаный код съест всю память и неподавится.

От того, что память будет дороже, код магически улучшится чтоль? Проблемы с памятью возникают (в порядке важности) 1) из-за убогости IDE, неспособной подсказать опасные моменты 2) из-за кривого дизайна языка-библиотек, где вручную занимаются низкоуровневой тривиальщиной 3) из-за невнимательного отношения к коду

"Машина должна работать, человек - думать". Комп должен максимально помогать обнаруживать проблеммные участки, зачем для такой ерунды напрягать мозг прогера??

> Жаль что программисты не уделяют достаточно внимания работе с ресурсами.

Ресурс "мозг" куда дороже сраной плашки памяти. Чем дешевле ресурс, тем глупее на нём экономить, тратя дорогие ресурсы. Даже поговорка такая была, в докомпьютерную эру: "Пока пятак искали, на рупь свечек сожгли" - очень хорошо здесь применима.

Ну вот этим мне и нравится лор:)

А теперь господин вам осталось только одно, сёгким движением языка убедить всех перейти скажем на зижарп ага ?:)

Ну разумеется я не пержу, по крайней мере это делать весьма затруднительно с помощью пальцев и клавиш. Ваши слова про 99% спорны хотя бы потому, что сейчас не 99% приложений его используют, а значит сказать с уверенностью просто нельзя. Вам конечно можно, а профессионалам нельзя, ибо не только ляпать, но и отвечать придётся.

Как я уже сказал, средств позволяющих 100% гарантировать отсутсвие утечек предостаточно, начиная от контроля, заканчивая прикручиванием автоматической сборки мусора к ручному выделению. То есть если сам забыл, то оно само собралось:)

Непродвинутым кодерам не место в профессии, их дело чистить сортиры, сливать помои, работать ртом и тд. Мы же не будем делать двухструнную гитару с 2мя ладами и автопозиционированием руки ради немузыкантов?

Ну а "тупой дизайн С" по работе с памятью он не тупой, он просто как бэ не мекает - делай так, как хочеш и будет так, как пожелаеш. Хочеш с gc, будет с ним родным, хочеш без - будет без него родного. Тем более что в крупных проектах чистую С библиотеку используют крайне редко в силу разных причин. А вот то, что человек может себе позволить высвобождать ресурсы, когда они ему не нужны _немедленно_ или грамотно перераспределять эти ресурсы, чтобы избежать лишней работы, это весьма пригождается. PS: gc не меняет никакой концепции, бросьте нести чуш. Это ещё одна надстройка для упрощения работы с выделением и высвобождением. Можно так, а можно эдак. Ещё чуток, и будете кричать девелоперс, девелоперс девелопер и забрызгивать слюной. PS2: чего-то проекты подобные mozilla не торопятся переходить на "самоуправствующие" технологии, а всё городят и городят свои велосипеды. Может от того всё таки, что разработчик лучше знает как использовать свои руки и мозг?

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

Какие к чёрту проблемные участки? Управление памятью - это не проблема. Программист знает, когда ему становится нужен объект (переменная, структура). Там он делает malloc или new. Программист знает, когда объект больше не нужен. Там он ставит free или delete. Всё. Родился - жил - умер. Если ты столь ленив, что не хочешь задумываться о том, когда объект больше не нужен - то будь последователен и не задумывайся о времени создания. Слабо?

Если free/delete стоит, то это не значит, что он вызовется. Есть много неочевидных случаев. Также не забываем про фрагментацию памяти и про то, что new/malloc в некоторых случаях неэффективны. Поэтому управление памятью это проблема, причем большая, а если вы её не видите, что значит у вас недостаточно опыта.

они сломали fgetln(), bastards!

говорила мне мама: не обновляйся до сдачи проэкта...