Алексей Махоткин

домашняя страница

Критика Standard ML — сборка мусора

Andrew W. Appel, «Критика Standard ML», оглавление

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

Даже со сборкой мусора программисту следует избегать ненужных указателей на ненужные объекты, чтобы программа не использовала слишком много памяти; иногда может потребоваться проанализировать и переписать некоторый участок программы, чтобы избежать слишком долгого существования структур данных. Однако, такая «настройка производительности» предпочтительнее, чем «настройка корректности», которая необходима в некоторых языках с явным оператором «избавиться от».

Без сборки мусора слишком сложно разработать безопасный язык, который умеет делать интересные штуки. Все современные языки из всех трех вышеперечисленных семей содержат динамическое выделение памяти. При этом, обычно, только языки из «математической» категории имеют автоматическую сборку мусора. В семьях BCPL и Algol динамические области памяти, которые более не используются, должны быть явным образом освобождены в программе, чтобы их можно было использовать повторно. Практически невозможно (то бишь, никто не знает, как) создать безопасный язык с явным освобождением памяти. Это основная, но не единственная, причина, по которой языки из семейства Algol не являются полностью безопасными.

В некоторых программах на C и на Pascal очевидно, где следует поместить операторы освободить или избавиться от. Однако, когда структуры данных становятся более сложными, все труднее и труднее предсказать, в какой именно точке следует избавляться от объектов. Программисты часто прибегают к явному подсчету ссылок, или даже к специализированным сборщикам мусора в стиле “mark-and-sweep”, которые реализуются заново для каждого класса записей.

Проблема становится еще хуже, когда в игру вступают модули. Если «серверный» модуль реализует абстракцию с помощью динамической памяти, то «клиентский» модуль не сможет узнать формат записи, чтобы должным образом избавиться от нее. При этом сервер не может узнать, когда клиент закончит работать с абстрактными объектами. Типичное решение этой проблемы — добавление в абстрактный интерфейс новых операторов освобождения абстрактных объектов. Это довольно быстро становится утомительным.

Ошибки выделения памяти могут повредить систему выполнения, и при этом остаться необнаруженными на протяжении многих миллионов операторов программы, которые будут выполнены после того, как произошла эта ошибка. Такие вещи особенно трудны для диагностики. Безопасные языки «математической» семьи, включая Standard ML, используют автоматическое управление памятью, и полностью избавлены от этого класса ошибок.

Comments