А так ли нужен сборщик мусора?

← →
Городской Шаман (2008-12-24 18:44) [0]

Одно из основных преимуществ, выдвигаемое фанатами управляемых языков, по типу Java и C# - сборщик мусора.

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

Вместо сборщика мусора я считаю оптимальным использование Interface или smart_ptr<>, которое позволяет автоматически управлять временем жизни объекта, но делать это осознанно.

← →
Игорь Шевченко © (2008-12-24 18:52) [1]

Джоэла Спольски читать. Наизусть.

← →
Игорь Шевченко © (2008-12-24 18:53) [2]

И кстати Рэймонда впридачу

← →
Riply © (2008-12-24 18:56) [3]

> [0] Городской Шаман (24.12.08 18:44)
> А так ли он важен и насколько он полезен для надежности и удобства проекта,
> ведь программист привыкнув что за него все сделает VM будет
> подсознательно ожидать что за освобождение системных ресурсов отличных от памяти позаботится среда.

Видела код сильного С-шника писаный на Delphi (да и в Delphi он не первый раз замужем :) ).
В нескольких местах он забывал "убирать за собой".
Конечно, единичный пример не доказательсто истинности твоего утверждения, но о чем-то говорит :)

← →
Правильный$Вася (2008-12-24 19:02) [4]

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

короче, реализация мусорщика имеет важное значение

← →
lucy (2008-12-24 19:08) [5]

>ведь программист привыкнув что за него все сделает VM будет подсознательно ожидать

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

← →
Eraser © (2008-12-24 19:22) [6]

> [0] Городской Шаман (24.12.08 18:44)

> А так ли нужен сборщик мусора?

нужен, НО с возможностью вызова деструктора вручную.

← →
Городской Шаман (2008-12-24 20:39) [7]

> Игорь Шевченко © (24.12.08 18:52) [1]
>
> Джоэла Спольски читать. Наизусть.

Он вроде бы тоже был против GC в качестве"серебряной пули". Или я читал не те его статьи?

← →
Городской Шаман (2008-12-24 20:45) [8]

> Игорь Шевченко © (24.12.08 18:52) [1]
>
> Джоэла Спольски читать. Наизусть.

Этот фрагмент?

Это отдельная песня: управление памятью. Вы знаете, как работает malloc? malloc поддерживает связный список свободных блоков памяти. Когда вы вызываете malloc, он проходит по списку в поисках блока достаточной длины. Найдя таковой, malloc разбивает его на две части (одна запрошенного размера, другая -- что осталось), кладёт остаток обратно в список свободных блоков, и возвращает указатель на блок запрошенного размера. Когда вы вызываете free, он просто добавляет освобождаемый блок в список свободных. Через какое-то время оказывается, что все свободные блоки маленькие, а нужен кусок побольше. Соответственно malloc объявляет перерыв и начинает перетряхивать список свободных блоков, сливая соседние маленькие блоки воедино, на что уходит три с половиной дня. В результате в среднем производительность malloc оказывается так себе (ему приходится постоянно ходить по цепочке свободных блоков), и иногда, внезапно, становится совсем никакой (когда приходится заниматься дефрагментацией). (Кстати, точно так же ведут себя и системы со сбором мусора, кто б мог подумать, так что заявления, которые часто можно услышать про неэффективность сборки мусора не совсем верны, ибо типичная реализация malloc обладает теми же самыми проблемами, хотя и в меньшей степени.)
http://russian.joelonsoftware.com/Articles/BacktoBasics.html

Но это не совсем верно, так как фрагментация памяти на современных страничных системах памяти совсем не проблема и + реализация эффективного менеджера памяти сводит на нет все проблемы с фрагментацией.

Проблема в другом - поведение программы (освобождение ресурсов) зависит от "научного прогноза астролога", если полагатся только на "умную" VM.

← →
Городской Шаман (2008-12-24 20:47) [9]

> Riply © (24.12.08 18:56) [3]
>
> > [0] Городской Шаман (24.12.08 18:44)
> > А так ли он важен и насколько он полезен для надежности
> и удобства проекта,
> > ведь программист привыкнув что за него все сделает VM
> будет
> > подсознательно ожидать что за освобождение системных ресурсов
> отличных от памяти позаботится среда.
>
> Видела код сильного С-шника писаный на Delphi (да и в Delphi
> он не первый раз замужем :) ).
> В нескольких местах он забывал "убирать за собой".
> Конечно, единичный пример не доказательсто истинности твоего
> утверждения, но о чем-то говорит :)

C++ не С. Объекты на стеке уничтожаются "магией компилятора", даже при исключении. С - это тот же assembler но с виртуальными регистрами (переменными).

← →
Городской Шаман (2008-12-24 20:50) [10]

> Eraser © (24.12.08 19:22) [6]
>
> > [0] Городской Шаман (24.12.08 18:44)
>
>
> > А так ли нужен сборщик мусора?
>
> нужен, НО с возможностью вызова деструктора вручную.

Тогда чем не устраивают interface или smart_ptr<>, кроме кольцевых ссылок (которые встречаются довольно редко и их можно разрулить) оно будет работать не хуже GC?

← →
Городской Шаман (2008-12-24 20:52) [11]

> lucy (24.12.08 19:08) [5]
>
> До первого отшибания сенсеем пальцев тетрадкой с нотами.
> Так что, считайте, что понятие "квалифицированный программист"
> включает в себя умение следить за ресурсами.

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

← →
lucy (2008-12-24 21:06) [12]

Городской Шаман (24.12.08 20:52) [11]

>так что "квалифицированных" в крупном проекте бывает не более 30%, остальное джониоры и сочувствующие.

Но вы ведь хотите стать квалифицированным программистом? Что еще вы можете сделать для отрасли, не являясь светилом Computer Science или крупным менеджером, почему-то вдруг решившим позаботиться о качестве?
Неужели у вас есть какие-то наполеоновские планы? Вы планируете встраивать умные указатели в Java и C#!?

← →
Игорь Шевченко © (2008-12-24 21:50) [13]

Городской Шаман (24.12.08 20:45) [8]

Нет, другой:

"Реальное и значительное повышение производительности мы получили от программирования на языках, автоматически управляющих памятью вместо вас. Это может быть подсчет ссылок или «сборка мусора», это может быть Java, Lisp, Visual Basic (даже 1.0), Smalltalk или любой язык написания скриптов. Если ваш язык программирования позволяет выделять кусок памяти без раздумий о его последующем освобождении, то вы используете язык с управляемой памятью, и вы будете значительно эффективней программиста, использующего язык, где управление памятью производится в явном виде"

http://russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html

← →
Городской Шаман (2008-12-24 22:52) [14]

> Игорь Шевченко © (24.12.08 21:50) [13]
> Если ваш язык программирования позволяет выделять кусок памяти без
> раздумий о его последующем освобождении, то вы используете
> язык с управляемой памятью, и вы будете значительно эффективней
> программиста, использующего язык, где управление памятью
> производится в явном виде"

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

Но если поиск нужно элемента из БД делать в виде "select * from xxx;" а далее по локейте или (while not tb.eof) искать нужный нам элемент, то никаких ресурсов не хватит. А GC поощряет ресурсоизбыточное программирование.

С точки зрения получения результата нет никакой разницы - составить ли грамотный селект или вытащить 10 млн записей на клиента и найти нужную обычным перебором. В результате необходимая запись все равно будет найдена.

← →
Игорь Шевченко © (2008-12-24 22:58) [15]

Городской Шаман (24.12.08 22:52) [14]

Пиши на ассемблере - твое полное право. Только не надо другим ничего доказывать.

← →
KilkennyCat © (2008-12-24 23:34) [16]

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

← →
Городской Шаман (2008-12-24 23:47) [17]

> KilkennyCat © (24.12.08 23:34) [16]
>
> я б вообще изменил всю логику. тянут мертвеца, а надо бы
> похоронить.

На какую?

← →
Городской Шаман (2008-12-24 23:47) [18]

> Игорь Шевченко © (24.12.08 22:58) [15]
>
> Городской Шаман (24.12.08 22:52) [14]
>
> Пиши на ассемблере - твое полное право. Только не надо другим
> ничего доказывать.

Если Lisp настолько хорош, то почему на нём не пишут?

← →
jack128_ (2008-12-25 00:06) [19]

> Если Lisp настолько хорош, то почему на нём не пишут?

потому что его его не поддерживает MS ?

← →
Игорь Шевченко © (2008-12-25 00:14) [20]

> Если Lisp настолько хорош, то почему на нём не пишут?

пишут

← →
XentaAbsenta © (2008-12-25 04:30) [21]

гм.. Я тоже вот задался таким вопросом после полутора лет проведённых на C#. В общем сделал вывод - кто-то там умный говорил, что в общем случае в программе не должно быть объектов, которые никому не принадлежат.
ИМХО: в программе архитектура первична, и если следовать мнемоническим правилам программирования, то GC не нужен и создан только для того, чтобы Sun и Microsoft могли заработать больше бабла.
---------------------
Почти в каждой программе используются системные ресурсы, в шарпе прямой вызов деструктора невозможен, остаётся писать IDisposable но весь фикус в том, что почти все классы со временем становятся IDisposable ибо окна, критические секции, мютексы (особенно именованые), файлы, подключения к БД, COM объекты (которые почему-то сами не релизятся... гм. странно), сокеты........
------
а вот строки массивы и списки - это тьфу!

← →
XentaAbsenta © (2008-12-25 04:31) [22]

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

← →
Городской Шаман (2008-12-25 05:40) [23]

> Игорь Шевченко © (25.12.08 00:14) [20]
> > Если Lisp настолько хорош, то почему на нём не пишут?
> пишут

Видно.
http://www.indeed.com/jobtrends?q=C%2B%2B%2C+Delphi%2C+Lisp&l=

← →
lucy (2008-12-25 07:56) [24]

Городской Шаман (24.12.08 23:47) [18]

>Если Lisp настолько хорош, то почему на нём не пишут?

http://www.paulgraham.com/popular.html

Из-за отсутствия критической массы библиотек продакшон уровня, в настоящий момент лисп является специализированным инструментом, примерно так же, как Delphi является средством для написания бухгалтерских приложений, и применяется там где нужна его динамика, символьные вычисления, DSL (для него существуют коммерческие IDE уровня Delphi: LispWorks, CormanLisp, доступны в условно-бесплатном варианте).

← →
Alkid (2008-12-25 11:40) [25]

> XentaAbsenta © (25.12.08 04:30) [21]
> ИМХО: в программе архитектура первична, и если следовать
> мнемоническим правилам программирования, то GC не нужен
> и создан только для того, чтобы Sun и Microsoft могли заработать
> больше бабла.

Ну это ты загнул. Сборщик мусора - штука полезная, но в рамках определённого круга задач. С другой стороны, есть языки, где сборщик мусора - это must have. Например - функционально-логические языки, использующие идиому IDS. Поскольку объект после создания и инициализации не может быть изменён, то он может быть переиспользован много раз в разных структурах, не принадлежа эксклюзивно никому. На смарт-поинтерах такую вещь решить сложно, ибо циклы.

← →
XentaAbsenta © (2008-12-25 12:42) [26]

что такое идиома IDS?

← →
Alkid (2008-12-25 13:51) [27]

> XentaAbsenta © (25.12.08 12:42) [26]
> что такое идиома IDS?

Immutable Data Structure. Т.е. когда у тебя объект во время создания/инициализации получает свои значения и не может быть изменён впоследствии. Распространено среди чистых декларативных языков.

← →
Alkid (2008-12-25 13:55) [28]

Вот тут ещё: http://en.wikipedia.org/wiki/Persistent_data_structure

> А так ли нужен сборщик мусора?

Кому нужен. Кому не нужен.
Это еще одно средство для борьбы со сложностью.
Набор для борьбы каждый выбирает сам.

ИМХО С++ обладает достаточным сборщиком.
Там нет проблемы со сбором мусора, пока не начинаешь работать напрямую с указателями.
При этом нет никаких проблем в том, чтобы указатели не использовать.
Подход: ты никогда не контролируешь сборку мусора - ИМХО не правильный.

Скажем так. Сборщик мусора - вещь полезная. Но и собственная забота о памяти - вещь тоже полезная. Посему, ИМХО, было бы неплохо "совмещать".

← →
Alkid (2008-12-25 14:34) [32]

> @!!ex © (25.12.08 14:23) [30]

ИМХО, неправильный подход - это делать слишком обобщающие заявления.
В некоторых ситуациях необходим контроль над управлением память, в некоторых такой необходимости нет, а в некоторых этот контроль просто вреден.
Обобщать какое-то специфическое отношение к GC на весь спектр задач неразумно.

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

Но есть моменты, где важно быстро и экономно ввиду объема и требованиям по времени - тама можно и пообсасывать без сборщика.

Но объемные и развесистые "склады" и т.п. писать на ассемблере - неразумно в плане затрат времени и оплаты высококвалифицированым разработчикам.

← →
int64 (2008-12-25 16:04) [34]

> XentaAbsenta © (25.12.08 04:30) [21]
> Почти в каждой программе используются системные ресурсы,
> в шарпе прямой вызов деструктора невозможен, остаётся писать
> IDisposable но весь фикус в том, что почти все классы со
> временем становятся IDisposable ибо окна, критические секции,
> мютексы (особенно именованые), файлы, подключения к БД,
> COM объекты (которые почему-то сами не релизятся... гм.
> странно), сокеты........!

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

Своевременное уничтожение объекта - это тоже средство обнаружения ошибок. Если я знаю, что с какого-то момента объект должен перестать существовать, и удаляю его, но по ошибке сохраняю на него ссылки, я (с большой вероятностью) получу ошибку, когда эти ссылки будут использованы. Это поможет мне обнаружить эти ссылки и исправить ошибку. А в системах со сборкой мусора просто явной ошибки не будет - забытые ссылки останутся, ненужный объект тоже останется, а программист, весьма вероятно, даже не заметит этой ошибки.

← →
int64 (2008-12-25 16:17) [36]

> Григорьев Антон © (25.12.08 16:05) [35]
> Если я знаю, что с какого-то момента объект должен
> перестать существовать

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

> А так ли нужен сборщик мусора?

Несколько утрируя, можно сказать, что если программист после New (GetMem, Create...) сразу же, на автопилоте пишет
try finally Dispose (FreeMem, Free...) end;
и только после этого начинает писать функциональный код в секции try...

... то такому программисту никакие сборщики мусора на фиг не нужны.

← →
Городской Шаман (2008-12-25 18:21) [38]

> int64 (25.12.08 16:04) [34]

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

Пусть сборщик будет, но будет управляемым, а не самодурствующим.

> int64 (25.12.08 16:04) [34]
>
> > XentaAbsenta © (25.12.08 04:30) [21]
> > Почти в каждой программе используются системные ресурсы,
>
> > в шарпе прямой вызов деструктора невозможен, остаётся
> писать
> > IDisposable но весь фикус в том, что почти все классы
> со
> > временем становятся IDisposable ибо окна, критические
> секции,
> > мютексы (особенно именованые), файлы, подключения к БД,
>
> > COM объекты (которые почему-то сами не релизятся... гм.
>
> > странно), сокеты........!
>
> Вообще-то, первое от чего надо отказаться при переходе на
> программирование с GC, это от привязки логики приложения
> к времени жизни объекта.
> Поэтому, даже внедрив самопристреливающиеся интерфейсы,
> ты не заменишь GC, если у тебя в деструкторах будут "закрываться"
> ресурсы.

Точно нужно отказаться?
IDisposable это просто шаблон детерминированной финализации ресурсов.
А как быть если IDisposable уже вызван, а ссылка на объект висит.
Это из той же серии, что и так называемое воскрешение объекта.

Клиент что, должен писать?

If someObject.ValidState then

Где здесь +?

← →
Городской Шаман (2008-12-25 19:07) [40]

> Юрий Зотов © (25.12.08 17:42) [37]
>
> > А так ли нужен сборщик мусора?
>
> Несколько утрируя, можно сказать, что если программист после
> New (GetMem, Create...) сразу же, на автопилоте пишет
> try
>
> finally
> Dispose (FreeMem, Free...)
> end;
> и только после этого начинает писать функциональный код
> в секции try...
>
> ... то такому программисту никакие сборщики мусора на фиг
> не нужны.

Но согласитесь, то написать вместо try...finally, smart_prt<> удобнее, так как не нужно явно писать код освобождения ресурса.

А так ли нужен сборщик мусора? Найти похожие ветки