Почему у Ады нет сборщика мусора?

Question

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

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

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

Answer 1

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

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

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

Заметьте, это не значит, что Ада имела всемирный успех.

Answer 2

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

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

Помните, что Ada была разработана в 1970-х и 1980-х годах, когда компьютеры были гораздо менее мощными, чем сегодня, и в управляющих приложениях вопросы синхронизации имели первостепенное значение.

Answer 3

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

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

• патч для GNAT
• Компиляторы Ada, ориентированные на виртуальную машину Java (я не знаю, поддерживаются ли эти проекты до сих пор).Он использовал сборщик мусора JVM.

В сети есть множество других источников о сборке мусора в Ada.эта тема подробно обсуждалась, в основном из-за жесткой конкуренции с Java в середине 90-х (см. эта страница: "Ada 95 is what the Java language should have been"), когда Java была «следующей большой вещью» до того, как Microsoft обратилась к C#.

Answer 4

Во-первых, в языке нет ничего такого, что запрещает вывоз мусора.

Во-вторых, некоторые реализации выполните сбор мусора.В частности, все реализации, предназначенные для сбора мусора JVM.

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

type Foo is access Blah;
for Foo'storage_size use 100_000_000; --// 100K

Если вы сделаете это, то вся (100 КБ) память, выделенная для объектов Blah, на которые указывают указатели Foo, будет очищена, когда тип Foo выйдет за пределы области видимости.Поскольку Ada позволяет вкладывать подпрограммы внутрь других подпрограмм, это особенно эффективно.

Чтобы узнать больше о том, что Storage_size и пулы хранения могут сделать для вас, см. ЛРМ 13.11

В-четвертых, хорошо написанные программы на Ada не так сильно полагаются на динамическое распределение памяти, как программы на C.В языке C было несколько дыр в дизайне, которые специалисты-практики научились закрашивать с помощью указателей.Многие из этих идиом не нужны в Аде.

Answer 5

Прежде всего, мне хотелось бы знать, кто сейчас использует Ada.Мне действительно нравится этот язык, и есть даже библиотека графического интерфейса для Linux/Ada, но я уже много лет ничего не слышал об активной разработке Ada.Благодаря его военным связям, я действительно не уверен, древняя ли это история или настолько успешная, что все упоминания о ее использовании засекречены.

Я думаю, что есть несколько причин отсутствия GC в Ada.Прежде всего, это восходит к эпохе, когда большинство компилируемых языков использовали в основном стек или статическую память или, в некоторых случаях, явное выделение/освобождение кучи.GC как общая философия действительно получила распространение только примерно в 1990 году или около того, когда ООП, улучшенные алгоритмы управления памятью и процессоры, достаточно мощные, чтобы сэкономить циклы для выполнения всего этого, вступили в свои права.То, что простая компиляция Ada могла сделать с мэйнфреймом IBM 4331 в 1989 году, было просто беспощадным.Теперь у меня есть сотовый телефон, который может превзойти по производительности процессор этой машины.

Другая веская причина заключается в том, что есть люди, которые думают, что строгий дизайн программы включает в себя точный контроль над ресурсами памяти и что не должно быть никакой терпимости к тому, чтобы позволить динамически получаемым объектам плавать.К сожалению, слишком много людей столкнулись с утечкой памяти, поскольку динамическая память все больше и больше становилась правилом.Кроме того, подобно «эффективности» ассемблера по сравнению с языками высокого уровня и «эффективности» чистого JDBC по сравнению с системами ORM, «эффективность» ручного управления памятью имеет тенденцию инвертироваться по мере масштабирования (я видел тесты ORM где эквивалент JDBC был вдвое менее эффективен).Я знаю, это противоречит здравому смыслу, но в наши дни системы намного лучше справляются с глобальной оптимизацией больших приложений, плюс они способны выполнять радикальную повторную оптимизацию в ответ на внешне незначительные изменения. Включая алгоритмы динамической перебалансировки на лету на основе обнаруженных изменений. нагрузка.

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

Answer 6

Я подумал, что поделюсь очень простым примером реализации процедуры Free() (которая будет использоваться способом, знакомым всем программистам на C)...

with Ada.Integer_Text_IO, Ada.Unchecked_Deallocation;
use Ada.Integer_Text_IO;

procedure Leak is
   type Int_Ptr is access Integer;
   procedure Free is new Ada.Unchecked_Deallocation (Integer, Int_Ptr);

   Ptr : Int_Ptr := null;
begin
   Ptr := new Integer'(123);
   Free (Ptr);
end Leak;

Вызов Free в конце программы вернет выделенное целое число в пул носителей («куча» на языке C).Вы можете использовать valgrind, чтобы продемонстрировать, что это действительно предотвращает утечку 4 байтов памяти.

Ada.Unchecked_Deallocation (обобщенная процедура) может использоваться (я думаю) для любого типа, который может быть выделен с помощью ключевого слова "new".Более подробную информацию можно найти в Справочном руководстве Ada («13.11.2 Неконтролируемое освобождение памяти»).

Answer 7

Ваш вопрос некорректен.Оно делает.См. пакет ada.finalization, который обрабатывает сбор мусора.