Почему у Ada нет сборщика "мусора"?

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

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

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

12
задан Lothar 19 October 2019 в 04:58
поделиться

5 ответов

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

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

Упрощенно: Сборщик мусора привносит в программу некоторую вариативность, которая не нужна дизайнерам. Вы наводите беспорядок - вы убираете его! Один и тот же код, одно и то же поведение каждый раз.

Не то чтобы Ада стала бешеным всемирным успехом, заметьте.

31
ответ дан 2 December 2019 в 02:59
поделиться

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

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

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

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

6
ответ дан 2 December 2019 в 02:59
поделиться

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

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

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

15
ответ дан 2 December 2019 в 02:59
поделиться

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

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

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

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

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

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

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

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

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

6
ответ дан 2 December 2019 в 02:59
поделиться

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

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

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

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

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

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

0
ответ дан 2 December 2019 в 02:59
поделиться
Другие вопросы по тегам:

Похожие вопросы: