Почему в других языках автоматический сборщик мусора не похож на Java-сборщик мусора?

Question

Каковы причины, по которым в других языках нет сборщика мусора?

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

Answer 1

Причины, по которым не нужно собирать мусор:

• Действительно эффективные коллекторы не были разработаны до 1985 года - 1990 года. Языки, разработанные до того времени, если эффективность была целью, не имеют сборки мусора. Примеры: Ада, Си, Фортран, Модула-2, Паскаль.

• Бьярн Страуструп считает, что лучше в языковом дизайне указывать все затраты и "не платить за функции, которые вы не используете". (См. Его статьи на 2-й и 3-й конференциях ACM по истории языков программирования.) Поэтому в C ++ нет сборки мусора.

• Некоторые исследовательские языки используют другие идеи (регионы, системы необычного типа) для явного, но безопасного управления памятью. Эти идеи особенно перспективны для таких проблем, как драйверы устройств, где вы не можете позволить себе выделять ресурсы, или для систем реального времени, где затраты памяти должны быть очень предсказуемыми.

Answer 2

Аппаратное обеспечение не имеет сборщика мусора ( было , некоторые аппаратные средства, которые имели элементарную поддержку для пересылки указателей, функция, полезная при создании некоторых сборщиков мусора, но это далеко от «GC в аппаратном обеспечении»). ). Соответственно, сборка не имеет ГХ. Ассемблер - это «язык программирования» (хотя и один из самых близких к «голому металлу»), так что вы идете: в широком спектре существующих языков программирования у некоторых не будет GC.

Бывает, что эффективный GC - это не то, что легко реализовать. Хорошие алгоритмы для этого были в разработке. Что еще более важно, большинство хороших алгоритмов GC хороши, потому что они выполняют некоторые сложные операции, такие как перемещение элементов данных в RAM; это необходимо для «реального времени GC», который предлагает гарантии на максимальное время, затрачиваемое на выделение (у вас не может быть таких гарантий при фрагментации, и вы не можете избежать фрагментации, не перемещая объекты в ОЗУ). Когда объект перемещается, все указатели на этот объект должны автоматически настраиваться, что может быть сделано только , если язык программирования предлагает сильные, неотвратимые типы. Например, это не может быть сделано с C или C ++. В C допустимо распечатывать байты, которые кодируют значение указателя, и затем пользователь вводит их обратно. GC не может изменить мозг пользователя, когда он перемещает объект ...

Таким образом, на практике языки без сильных типов не содержат GC. Это включает в себя C, C ++, Forth, все виды языков ассемблера с расширениями ... Это не мешает некоторым людям писать реализации GC для таких языков, например, Ганс Бем ГК для C и C ++ . Тем не менее, это означает, что сборщик мусора может потерпеть неудачу с (странными) программами, которые номинально "легальны" в отношении языкового стандарта.

Существуют также языки со строгими типами, но без GC, либо потому, что их разработчики не верили в это, либо полагали, что могли бы добиться большего успеха без дополнительного размера кода, либо извлекали выгоду из него (например, Javacard, Java для смарт-карт). , меньше GC, потому что установка GC в среде с 8 КБ кода и 512 байтами ОЗУ не просто).

Наконец, среди тысяч языков программирования, которые были разработаны («однажды в неделю, начиная с шестидесятых», как мне когда-то сказали), некоторые являются результатом поздних разговоров после слишком большого количества алкоголя, поэтому он не может Предполагается, что каждая функция или не все функции языков программирования являются результатом сбалансированного рационального мышления.

Answer 3

«Другие языки» делают - этот вопрос помечен C#, а .NET CLR наиболее точно выполняет автоматическую сборку мусора.

Я могу придумать несколько причин, по которым C ++ его не имеет:

• Весь существующий код на C ++ использует явное управление памятью, поэтому реализация сборки мусора была бы серьезным изменением;

• По тому же признаку. Программисты на C ++ уже привыкли к явному управлению памятью, поэтому сборка мусора не так важна;

• Хорошо алгоритмы сборки мусора довольно новы, и C ++ предшествует им совсем немного. Сборка мусора является горизонтальной функцией, и разработчики языка должны будут внести серьезные (и сложные) изменения в спецификацию. Проще говоря, сборщик мусора сложнее привязать к существующему языку, чем спроектировать его с самого начала, как это было с .NET и Java.

• Java работает на виртуальной машине, и .NET использует нечто подобное, тогда как C ++ работает с собственным кодом. GC гораздо проще рассуждать в первом случае.

• C ++ часто используется для приложений, которые должны работать при жестких требованиях к памяти (например, встроенные системы), и в этих случаях необходимо явное управление памятью. Я полагаю, что своего рода GC "opt-in" мог бы решить эту проблему, но это даже сложнее для разработчиков языка для правильной реализации.

Answer 4

Люди уже ответили на ваш вопрос, но, тем не менее, в вашем вопросе есть скрытое утверждение: «Сборка мусора - это решение всех проблем», и я хотел бы обсудить это утверждение ...

GC - не единственный способ обращения с памятью

Существует как минимум три способа управления распределением памяти:

• вручную
• Сборка мусора
• RAII

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

GC не обрабатывает утечки ресурсов

В программе много ограниченных ресурсов, помимо памяти:

• файловые дескрипторы
• другие дескрипторы ОС
• сетевые подключения
• соединения с базой данных
• и т.д.

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

Эти ресурсы обычно должны быть получены и получены вручную на языках, основанных на GC (то есть на Java). Если вы хотите увидеть, насколько уродливым это может быть, посмотрите на этот вопрос:

RAII в Java ... удаление ресурсов всегда так безобразно?

RAII обрабатывает утечки памяти и ресурсов

Использование идиомы RAII позволит вам писать читаемый код, без каких-либо утечек, памяти или чего-либо другого. На самом деле я не могу вспомнить время, когда при написании кода на C ++ меня беспокоило распределение / освобождение памяти, несмотря на то, что я не использую сборщик мусора.

Но я четко помню, что в октябре 2008 года мне пришлось справиться с утечкой ресурсов в Java, и решение было настолько уродливым, что было отвратительно.

Заключение * * тысяча пятьдесят-одна Каковы причины, по которым в других языках нет сборщика мусора? Ответ может быть: потому что в то время GC не был достаточно эффективным потому что GC не является решением всех утечек потому что в этом нет необходимости. C ++ больше в разделе "в этом нет необходимости". GC может быть отличным бонусом к RAII в C ++ (см. Сборка мусора в C ++ - почему? ), но я никак не могу обменять свой RAII на ваш GC. Ever.

Answer 5

Некоторые языки старые. Например, C, который изначально был разработан для системного программирования на машинах, намного медленнее, чем сегодня. Сборка мусора, вероятно, тогда не существовала (ну, может, Lisp?), И даже если бы она существовала, разработчики не хотели бы тратить все циклы ЦП и накладные расходы на сборку мусора, когда программисты могли бы сделать это самостоятельно. А поскольку машины были намного менее мощными, программное обеспечение было проще, и, следовательно, программистам было проще управлять памятью вручную, чем в гораздо больших приложениях, которые могут быть написаны сегодня.

Answer 6

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

Answer 7

Если вы не знаете почему, это из-за денег. В первые дни компьютеры были дорогими, а программисты - дешевыми. Сейчас 180 градусов разные - компьютеры дешевые, а программисты дорогие. GC нужно немного процессора, чтобы выполнить свою работу.

Кроме того, большинству сборщиков мусора иногда приходится останавливать программу для выполнения полной развертки. В программном обеспечении реального времени - промышленный мониторинг, фондовый рынок и т. Д. - это не вариант. И иногда клиенты могли видеть это тоже в одном из приложений, которые я разработал (веб-сайт ASP.NET иногда зависал на минуту или около того).

Другая причина - никто не идеален, и GC потенциально может получить некоторые утечки. Если вы пишете осторожно с некоторыми языками, не относящимися к GC, это маловероятно.

Answer 8

На самом деле GC для C и C ++ здесь .

Но в целом сообщества C / C ++ с первого дня развили отвращение к изучению многих успешных функций языка программирования, которые широко использовались в сообществах динамических языков, начиная с GC. Отчасти, я думаю, что этот феномен возник из культуры Bell Labs; у вас была куча хардкорных кнутов, умных людей, которые были убеждены, что знают лучше, и что им не нужны языковые функции для снижения уровня дефектов. Вот почему строки C - кошмарная дыра в безопасности, которая до сих пор создает огромные проблемы с безопасностью: потому что группа хакеров Bell Lab знала , просто знала, что они могут написать безопасный безопасный код, даже если API был сделан из бритвенных лезвий и нитроглицерина. Идеальным программистам не нужны сетевые строки, а идеальным программистам не нужен GC. Жаль, что нет идеальных программистов. Уверенность важна, но смирение удерживает нас от разрушения.

Answer 9

C, C ++, Java и C # были созданы в разные моменты времени (и в таком порядке). И Java, и C # имеют сборку мусора.

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

Answer 10

Более современные языки, такие как C # и java, имеют сборщик мусора, потому что писать код проще, если вам не нужно беспокоиться об управлении памятью. Старые языки не делают. Существует также много приложений (например, встроенных приложений, работающих без какого-либо доступа к виртуальной памяти), где вам необходимо точно определить, сколько памяти будет использовать ваше приложение, и для них такой язык, как C ++, является более подходящим. Приложения реального времени также могут ограничивать вашу способность использовать язык, предназначенный для сбора мусора, так как вы должны полностью контролировать, как быстро ваше приложение реагирует в любое время.