Зачем нужны GC, Java, .NET?

Кроссплатформеность же. Твой код на вале можно написать на x86, а запустить на арме? То-то же.

Я не хочу спорить об этом свойстве джаваподобных технологий. Топик не о том.

Замечу только, что свой код на Genie я запущу везде, где запускаются gtk-приложения. Выгода от одного бинарника для разных платформ очевидна разве что для мобильных устройств, да и то спорно.

> Имеем для каждого объекта счетчик ссылок на него. Исчезает последняя ссылка --> объект удаляется. Запрещаем при этом ручную работу с указателями. Получаем то же самое, что и в Java или .NET, но без огромного оверхеда.

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

потом ещё какие-нибудь фичи и в итоге получим свой явовелосипед. С таким же оверхэдом.

При этом они не таскают за собой большую дуру под названием JVM и работают куда быстрее.

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

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

когда это нужно зависит от ситуации

Все эти умные указатели хороши, но пока ты используешь их на небольшом участке кода. В огромных проектах, и в говнокоде (коим являются большинство ынтырпрайзных проектов на жаве и дотнете) они становятся адом: сложно отследить удаление объекта, еще сложнее отследить удаление в асинхронных обработчиках, утечка памяти при циклических ссылках, нетривиальная обработка этих циклических ссылок (Vala вроде этим страдает как и C++) и т. п. А индусу дали сборщик мусора, он налабал говнокода, ну и что то 4 гига отожрало, зато не течет, и иногда само подчищается за собой :)

>Имеем для каждого объекта счетчик ссылок на него. Исчезает последняя ссылка --> объект удаляется. Запрещаем при этом ручную работу с указателями. Получаем то же самое, что и в Java или .NET, но без огромного оверхеда.

Ты дурак или тролль, только честно?

Да ну, бред. Не начнем мы хотеть ничего другого - этого уже более чем достаточно. Простой счетчик ссылок - это далеко не то, что в Java называется GC. И это не нужно таскать за собой - достаточно иметь рантайм с поддержкой этих фич, как например в GLib.

И GC, по сравнению с этим простым принципом, не уменьшает число багов. Ну вот никак не уменьшает. Можете давить на крутую оптимизацию, вот только без GC программы работают быстрее - факт (точнее, с меньшим лейтенси, но не суть важно).

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

А индусу дали сборщик мусора, он налабал говнокода, ну и что то 4 гига отожрало, зато не течет, и иногда само подчищается за собой :)

Лопнешь же.
http://lurkmore.ru/Небыдло

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

Умные указатели рулят, но не заруливают. На циклических связях они текут.

А почему, собственно, рулят(в сравнении с GC, я так понимаю)?

Минус оверхед по занимаемой памяти, минус оверхед в виде VM, минус существенная лейтенси. Этого не достаточно, чтобы рулить как минимум на десктопах? Практика показывает, что достаточно.

>А почему, собственно, рулят(в сравнении с GC, я так понимаю)?

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

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

В GObject для такого специально предусмотрено многопроходное удаление.

Куча проходов это уже не шустро. Если в языке есть ручное управление памятью, лучше в таких случаях это вручную разруливать, имхо.

Деструкторы С++ решают все вопросы с освобожением занятой памяти и других ресурсов. Никаких утечек памяти абсолютно нет. GC не нужны.

>Минус оверхед по занимаемой памяти
Это по дополнительному машинному слову(условно) на каждый указатель то - меньше памяти?

минус оверхед в виде VM

Что такое VM? Какое она отношение имеет к, собственно, сборщику? На досуге, кстати, посмотри сколько занимают рантаймы Си, и, особенно, C++ в современных системах.

минус существенная лейтенси

Бред. Доступ к объекту - разыменование указателя и в GC и тут. Создание объекта - выделение памяти и там и тут, создание и удаление ссылки - в случае счетчика ссылок даже более затратная операция, чем в случае GC(счетчик этот инкрементировать и декрементировать надо постоянно).

Это из серии «вредные советы». Толикой скорости можно пожерствовать, если это толика, а не что-то громадное.

anonymous (*) (16.12.2009 18:13:45)

Деструкторы С++ решают все вопросы с освобожением занятой памяти и других ресурсов. Никаких утечек памяти абсолютно нет. GC не нужны.

У указателей в С++ появились деструкторы? И давно?

> Не начнем мы хотеть ничего другого - этого уже более чем достаточно.

Тогда в твоём случае действительно использование «умных указателей» в той или иной имплементации будет выгоднее.

Я же указал хотя бы 1 вещь, которую может хотеться. Это то что явамашина сама выделяет память заранее и при создании нового объекта не происходит системных вызовов по выделению памяти. Результат более быстрое создание объектов (как даже тут было продемонстрировано), цена - ну тут и так всё понятно :). Навскидку придумать других бонусов не удалось.

Простой счетчик ссылок - это далеко не то, что в Java называется GC.

И это не нужно таскать за собой - достаточно иметь рантайм с поддержкой этих фич, как например в GLib.

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

И GC, по сравнению с этим простым принципом, не уменьшает число багов. Ну вот никак не уменьшает. Можете давить на крутую оптимизацию, вот только без GC программы работают быстрее - факт (точнее, с меньшим лейтенси, но не суть важно).

так, не путай теплое с мягким. Без GC программа будет работать быстрее - согласен. GC не уменьшает число багов - не согласен: возьмём сферического программиста, в случае с gc у него есть мест, где он может потенциально ошибиться, без gc - у него ровно столько же мест + ещё управление памятью на нём.

Итого мы получаем, что технологию нужно использовать там, где она выгода. Ява - интырпрайз, и там это оправдано :)

>Шустро
Чем принципиально шустрее GC - непонятно мне совсем.

удобно

Ну в сравнении с malloc/free или new/delete в полностью ручном режиме - безусловно.

> У указателей в С++ появились деструкторы? И давно?

Со времен появления указателей

Лабы то все сдал?

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

Программы же на GObject кушают даже меньше, чем на Qt без смартпоинтеров. Это ответ на вот этот бред:

Это по дополнительному машинному слову(условно) на каждый указатель то - меньше памяти?

> Лабы то все сдал? То, что он ничо не делает не озночает его отсутвие.

> Ты дурак или тролль, только честно?

http://lurkmore.ru/Небыдло

Ну кто бы говорил. )))

> И без циклических ссылок можно обойтись, если автоматически перенаправлять ссылку на сам объект

Нельзя. man циклические очереди и т.п.

> Это то что явамашина сама выделяет память заранее и при создании нового объекта не происходит системных вызовов по выделению памяти.

Ты говоришь это так, будто CRT работает по другому...

>Минус оверхед по занимаемой памяти,

Либо используешь структуры фиксированного размера на стеке или в преаллоцированном пуле либо используешь GC либо эмулируешь ту же самую GC. Быть «немножко беременной» не получится.

минус оверхед в виде VM

Каким макаром связан VM и GC?

минус существенная лейтенси.

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

> чем это принципиально отличается от «При этом они не таскают за собой большую дуру под названием JVM и работают куда быстрее.», кроме отсутствия промежуточного байткода?

Тем, что мы видим в реальной жизни при запуске сферической Gtk-программы и сферической Java-программы.

без gc - у него ровно столько же мест + ещё управление памятью на нём.

Почему я в Genie не управляю памятью в таком случае? В Genie нет GC.

>Чем принципиально шустрее GC - непонятно мне совсем.

Я же написал, что некомпитентен спорить по поводу смартпоинтер vs GC.

>Это из серии «вредные советы». Толикой скорости можно пожерствовать, если это толика, а не что-то громадное.

Можно. Но не всегда.

http://prisms.cs.umass.edu/emery/

http://cs.anu.edu.au/~Steve.Blackburn/pubs/index.html

а подсчёт ссылок - это детский сад, вообще говоря

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

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

Программы же на GObject кушают даже меньше, чем на Qt без смартпоинтеров. Это ответ на вот этот бред:

А как относится к теме сравнение glib и qt? В каком из них есть GC?

Таким хамлом как love5an от лиспа становятся?

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

Насчет производительности можно повременить. Но чем вы объясните избыточный расход памяти, если не GC?

А как относится к теме сравнение glib и qt? В каком из них есть GC?

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

И где ты такие вкусные ссылки находишь?

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

А что GC объекты прибивает, выполняясь строго в параллельной вселенной? Или в общем случае ты готов гарантировать, что он не сработает до того, как клиенту вернется результат?
Под latency относительно GC обычно понимается именно невозможность связать момент освобождения памяти с временем жизни объекта. Иногда это критично.

Это от Лиспа или от Жабы такие умозаключения? На утверждение про освобождение ресурса по имени «память» с помощью деструкторов появляется ответ про какие-то указатели.

По GC: Предложенный вариант очень медленнен. Оверхед на него огромен. Единственная выгода - предсказуемость. GC на порядки производительней на реальных программах. Так же предложенный вариант не чистит память при циклических ссылках.

А JVM это далеко не только GC.

И где ты такие вкусные ссылки находишь?

агрегирую. если бы я ещё успевал их все читать :(

> Ты говоришь это так, будто CRT работает по другому...

я думал, что в с/c++ при new или malloc память будет выделяться в момент вызова, если делать это без дополнительных изменений или использования тулкитов.

Если не так поправь.

http://www-plan.cs.colorado.edu/diwan/recentpapers.htm#Memory%20Management

вот ещё полезного чтива

задание на дом «как будут себя вести счетчики ссылок при использовании циклических структур данных...»

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

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

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

> Тем, что мы видим в реальной жизни при запуске сферической Gtk-программы и сферической Java-программы.

сферическая gtk програма нативная, сферическая jaa программа на байткоде. В сферической явапрограмме классы используются всезде, где надо и где нет и итоге появляются много мест где теряется производительность. Но это не вопрос про gc :).

Почему я в Genie не управляю памятью в таком случае? В Genie нет GC.

круто тебе, что врать :). Сравнивать genie и яву я не могу, т.к. с genie совсем не знаком.

Задание на дом: почитать про управление памятью в glib и про то, что такое «ручное выделение памяти».

Поправляю: с/c++ при new или malloc память будет выделяться в момент вызова, но без гарантированного _системного_ вызова. Аллоцируется сразу заметная куча, из которой выдаётся нужный объем.

Спасибо. Посещение лора в этот день было не напрасным. )))

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

А что GC объекты прибивает, выполняясь строго в параллельной вселенной? Или в общем случае ты готов гарантировать, что он не сработает до того, как клиенту вернется результат?

Учитывая сколько времени треды висят на IO и на мутексах время вполне можно выкроить.

Под latency относительно GC обычно понимается именно невозможность связать момент освобождения памяти с временем жизни объекта

То что на Си для подстраховки постоянно дублируют куски памяти когда отдают их внешнему коду тоже не очень хорошо.

Love5an, подозреваю, что этот тред будет недолгим. Потому как скучно... Да, про лисп, я думаю, лучше не говорить :)

А деструкторы объектов разве не могут уменьшить количество ссылок у совместно используемого ими объекта? И сам разделяемый объект удалит себя после обнуления ссылок на него. И никакой утечки памяти нет.