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

← →
Городской Шаман (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<> удобнее, так как не нужно явно писать код освобождения ресурса.

← →
Юрий Зотов © (2008-12-25 19:45) [41]

> Городской Шаман (25.12.08 19:07) [40]

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

> не нужно явно писать код освобождения ресурса.
1. Если этот ресурс - память, то написать короткое слово Free - не в лом.
2. А если это не память, то писать код освобождения все равно придется.

← →
Игорь Шевченко © (2008-12-25 19:48) [42]

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

← →
@!!ex © (2008-12-25 20:02) [43]

> [42] Игорь Шевченко © (25.12.08 19:48)

речь не о том, что не должно быть сборщика. речь о том, что до маразма доходить не должно.

← →
DVM © (2008-12-25 21:11) [44]

Сборщик мусора вещь конечно удобная, но предмет явно не первой необходимости. Меня лично как то всегда коробит тот факт, что где то, например, в C# я создаю объект, который потом когда то, причем не сразу, а может и никогда, если необходимости нет, будет освобожден GC.

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

← →
Игорь Шевченко © (2008-12-25 21:17) [45]

@!!ex © (25.12.08 20:02) [43]

> речь не о том, что не должно быть сборщика. речь о том,
> что до маразма доходить не должно.

Что есть маразм ?

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

> Игорь Шевченко © (25.12.08 19:48) [42]
>
> почему никого не удивляет, что у длинных строк, интерфейсов
> и динамических массивов есть "сборщик мусора" ? Может, ревнителям
> ручного управления памятью стоит озаботиться финализацией
> этих типов по мере их ненадобности ?

Например тем что все три типа объектов в качестве ресурса используют только память, не затрагивая остальные ресурсы.

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

> Игорь Шевченко © (25.12.08 21:17) [45]
> Что есть маразм ?

Практическая остановка работы программы, когда этого захотелось сборщику, что в системах online-времени может вызвать проблемы. Если сервер "станет" на 10 секунд это может быть заметно, а такое на ASP.NET или C# вполне возможно.

← →
Игорь Шевченко © (2008-12-25 22:04) [48]

Городской Шаман (25.12.08 21:54) [46]

> Например тем что все три типа объектов в качестве ресурса
> используют только память, не затрагивая остальные ресурсы.
>

Не знаю, как в других языках, а в .Net эта проблема вроде как решена - Рихтер, по крайней мере довольно много писал на эту тему. Может, стоит почитать ?

Городской Шаман (25.12.08 21:57) [47]

> Практическая остановка работы программы, когда этого захотелось
> сборщику, что в системах online-времени может вызвать проблемы.
> Если сервер "станет" на 10 секунд это может быть заметно,
> а такое на ASP.NET или C# вполне возможно.

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

Может, опять же, стоит побольше почитать прежде чем устраивать флейм ?

← →
boa_kaa © (2008-12-25 22:04) [49]

> Городской Шаман (25.12.08 21:57) [47]

садись за Рихтера
прямо сейчас
чтобы едундой больше не болтать

← →
Псалтырь © (2008-12-25 22:56) [50]

> Игорь Шевченко © (25.12.08 19:48) [42]
>
> почему никого не удивляет, что у длинных строк, интерфейсов
> и динамических массивов есть "сборщик мусора" ?

Но и этим дядям иногда приходится звать на помощь Finalize. И задолбается искать тот, кто свято верит в непогрешимость самоубиения длинных строк.

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

> boa_kaa © (25.12.08 22:04) [49]
>
>
> > Городской Шаман (25.12.08 21:57) [47]
>
> садись за Рихтера
> прямо сейчас
> чтобы едундой больше не болтать

Я знаю про using, но в чем удобство по сравнению с тем же C++ + STL и basic_string ? То же самое но типа со сборщиком мусора, который собирает ошмётки полууничтоженных объектов(в которых вызвали Dispose, а удалить не удалили).

← →
boa_kaa © (2008-12-25 23:35) [52]

> Городской Шаман (25.12.08 23:29) [51]

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

ЗЫ. Извиняюсь, если грубовато получилось

← →
oxffff © (2008-12-26 00:12) [53]

>Игорь Шевченко © (25.12.08 22:04) [48]
>boa_kaa © (25.12.08 22:04) [49]

>
> > Городской Шаман (25.12.08 21:57) [47]
>
> садись за Рихтера
> прямо сейчас
> чтобы едундой больше не болтать

А сами то читали Рихтера?
Если нет, тогда читать книгу которая от 2007 CLR via C#.
стр. 504-507.

Так ли все там хорошо, как хотите представить?

← →
boa_kaa © (2008-12-26 00:16) [54]

> oxffff © (26.12.08 00:12) [53]

конкретный абзац, который докажет обратное

← →
oxffff © (2008-12-26 00:21) [55]

> boa_kaa © (26.12.08 00:16) [54]

Я же написал стр. 504-507 внимательно.
Прочитайте что делается с потоками при сборке и как.

← →
oxffff © (2008-12-26 00:22) [56]

> boa_kaa © (26.12.08 00:16) [54]
>
> > oxffff © (26.12.08 00:12) [53]
>
> конкретный абзац, который докажет обратное

Тогда и я позволю себе задать аналогичный вопрос.

Конкретный абзац, который докажет то что вы утвержаете?

← →
Игорь Шевченко © (2008-12-26 01:09) [57]

oxffff © (26.12.08 00:21) [55]

Я не настолько богат, чтобы покупать все книги Рихтера. Процитировать не затруднит ?

← →
Городской Шаман (2008-12-26 01:37) [58]

> Игорь Шевченко © (26.12.08 01:09) [57]
>
> oxffff © (26.12.08 00:21) [55]
>
> Я не настолько богат, чтобы покупать все книги Рихтера.
> Процитировать не затруднит ?

С этим вы согласились, что попытки обвинить компилятор в ошибках программиста ни к чему хорошему приведут? Но разработчики .NET похоже считали что их продукт будут использовать полные идиоты, которые не способны понять что же именно должен делать их код. И у них получилось, так как программы джониоров на C# или Java это тихий ужас, но который используется так как чуть-чуть работает.

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

← →
boa_kaa © (2008-12-26 01:41) [59]

> oxffff © (26.12.08 00:21) [55]

читал
и что?
что там такого СТРАШНОГО и ХМУРОГО?

← →
boa_kaa © (2008-12-26 01:45) [60]

> Отсюда и проблема современного ПО (его глюков и кривизны),
> так как по мнению ведущих корпораций программист не должен
> быть умнее домохозяйки, а эволюционно все стремится к минимальному
> уровню, в данном случае - уровню IQ.

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

← →
Городской Шаман (2008-12-26 02:04) [61]

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

Только этот "современный программист" напоминает фельдкурата Отто Каца у которого в помощниках бравый солдат Швейк(GC). С управляемыми языками все логично, если не обращать внимания на странности.

← →
boa_kaa © (2008-12-26 02:07) [62]

а странности - они везде есть

← →
Игорь Шевченко © (2008-12-26 02:07) [63]

Городской Шаман (26.12.08 01:37) [58]

"Вы, сударь, чепуху говорите и возмутительнее всего то, что говорите ее безапелляционно и уверенно."
(с)

← →
Eraser © (2008-12-26 02:11) [64]

> [58] Городской Шаман (26.12.08 01:37)

> Отсюда и проблема современного ПО (его глюков и кривизны)
> , так как по мнению ведущих корпораций программист не должен
> быть умнее домохозяйки, а эволюционно все стремится к минимальному
> уровню, в данном случае - уровню IQ.

пустые слова. примеры такого кривого современного ПО в студию.

между тем, на java"е написаны лучшие, на мой взгляд, IDE - eclipse, zend, netbeans - уж намного лучше и быстрее работают, чем IDE Delphi. offtop: кстати еще насчет языков со сборкой муссора - в новой CDS 2009 (вышла в этом месяце) есть поддержка .NET, совместимая с mono, вроде целая новая IDE - еще одна попытка внедрить кроссплатформенность.

← →
Городской Шаман (2008-12-26 02:12) [65]

> Игорь Шевченко © (26.12.08 02:07) [63]

Вот он уровень современного программиста

Вот в хелпе для каждой функции указана, thread-safe она или нет. А как свою собственную функцию сделать потокобезопасной ?
http://sql.ru/forum/actualthread.aspx?tid=626371

Здравствуйте!

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

Подскажите пожалуйста, как решаются такие проблемы, в каком направлении копать.
http://sql.ru/forum/actualthread.aspx?tid=626009

С первой формы запускается вторая.
Нужно присвоить значение из TextBox на первой форме Labelу на второй.

Пробовал разные варианты, но пока только вылетают ошибки.
http://sql.ru/forum/actualthread.aspx?tid=625958

Если бы вместо сборщика мусора написали заменитель мозгов...

← →
Игорь Шевченко © (2008-12-26 02:14) [66]

Городской Шаман (26.12.08 02:12) [65]

Вот он, уровень современного программиста:
http://www.delphimaster.ru/cgi-bin/forum.pl?n=18

Зато какой фон замечательный, а ?

Ничего, не ты первый, не ты последний.

← →
KilkennyCat © (2008-12-26 02:19) [67]

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

← →
Городской Шаман (2008-12-26 02:35) [68]

> Игорь Шевченко © (26.12.08 02:14) [66]

Мастерство программиста не в том, чтобы писать программы, работающие без
ошибок, а в том, чтобы писать программы, работающие при любом количестве
ошибок? (с) ankdot.ru

← →
Ans (2008-12-26 03:24) [69]

> Игорь Шевченко © (25.12.08 19:48) [42]
> почему никого не удивляет, что у длинных строк, интерфейсов
> и динамических массивов есть "сборщик мусора" ? Может, ревнителям
> ручного управления памятью стоит озаботиться финализацией
> этих типов по мере их ненадобности ?

Причем все указанные выше элементы могут быть уничножены ручками, так то:

для строки SetLength в 0
для динамического массива SetLength в 0 + можете указатель в nil
для интерфейсов - ну это позор не помнить про IUnknown.Release

← →
test (2008-12-26 07:04) [70]

Eraser © (26.12.08 02:11) [64]
Проведи эксперемент оставь запушенными в свернутом виде Дельфи и Eclipse, потом обоих разверни, получившийся эффект это как раз сборщик. Можно еще запустить Eclipse из под приложения логируещего состояние памяти, тоже посмотри что осталось в памяти и возрадуйся. Вообще на Java простой приклад который разок сработал и умер работает с каким угодно количеством не убитых обьектов в памяти. Проблемы начинаются если пишеш 24/7.

> Ans (26.12.08 03:24) [69]
> для интерфейсов - ну это позор не помнить про IUnknown.Release

Вот только вручную этот Release в Delphi вызывать не надо. Потому что при выходе интерфейсной переменной из области видимости или изменении её значения компилятор всё равно вызовет Release, а два Release"а одному интерфейсу ни к чему хорошему не приводят. Можно, конечно, извратиться и обнулить потом указатель низкоуровневыми средствами, но зачем? Проще сразу присвоить nil.

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

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

> boa_kaa © (26.12.08 01:41) [59]
>
> > oxffff © (26.12.08 00:21) [55]
>
> читал
> и что?
> что там такого СТРАШНОГО и ХМУРОГО?

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

Однако сам код финализации может быть очень time consuming, и при обработке целого массива объектов. Тогда при использовании детерменированной финализации c IDispose, т. е. с размазыванием по времени превращает такого рода решение, исключительно в работу обычного менеджера памяти с отложенным освобождением памяти(чего можно добиться и в native Delphi с небольшой манипуляцией с Tobject.FreeInstance), однако с тем лишь исключением что при при дефрагментациии .NET корректирует
Managed pointers (type &) и Object references (type O), а у native этого нет.
Однако для больших объектов дефрагментация по возможности не используется. Так что в определенных ситуациях больше минусов, чем плюсов.
Я конечно уверен, что есть различные стратегии работы GC, однако они хорошо работают для одних задач и совершенно не работают для других.
Например я имею дело с real time приложением(распознаванием номеров) написанным на unmanaged С++ и C#. Разработчикам этого приложения пришлось переносить часть логики на С++ а для C# использовать детерминированное освобождение по причине того, что просто при сборке мусора приложение просто не обрабатывало входящий видеопоток. А минусы которого IDispose я уже упомянул выше в oxffff © [39].

> boa_kaa © (26.12.08 01:41) [59]
>
> > oxffff © (26.12.08 00:21) [55]
>
> читал
> и что?
> что там такого СТРАШНОГО и ХМУРОГО?

Теперь жду от вас разъяснение о полной свободе при GC.

> Игорь Шевченко © (26.12.08 01:09) [57]
> oxffff © (26.12.08 00:21) [55]
>
> Я не настолько богат, чтобы покупать все книги Рихтера.
> Процитировать не затруднит ?

Книги дома, я на работе. :)

> [70] test (26.12.08 07:04)

я сейчас как раз плотно работаю почти одновременно на Делфи и NetBeans - последний ощутимо шустрее работает. в Java"e несколько подходов к сборке муссора, в зависимости от разных условий применяются разные подходы.

← →
test (2008-12-26 10:08) [76]

Eraser © (26.12.08 10:01) [75]
Продукт имеет требование 24/7? Если нет всех прелестей Java не увидиш.
NetBeans имеет кучу нативных библиотек казалось бы а зачем они нужны?

← →
test (2008-12-26 10:11) [77]

Eraser © (26.12.08 10:01) [75]
Много вариантов сборки это случаем не два?
1. Проверяем все вплоть до температуры пользователя перед удалением
2. Не проверяем так много но тоже долго

> [76] test (26.12.08 10:08)

что значит 24/7? чтобы была 100% вероятность круглые сутки получать отклик от машины не дольше чем за 1 секунду?

> Много вариантов сборки это случаем не два?

как минимум два, возможно уже больше.

← →
test (2008-12-26 11:16) [79]

> [79] test (26.12.08 11:16)

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

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