September 27th, 2012

flow

Не надо мусорить

Большинство современных языков программирования сейчас пользуются какой-либо техникой сборки мусора (garbage collection).

Это прекрасно работает для больших объёмов свободной памяти и immutable данных. У неизменяемых данных нет модальности, состояния, а значит, не может быть и владельца. Можно копировать сами данные, можно копировать ссылки, а потом выкидывать ненужные копии по счётчику или циклу сборки мусора. Иногда - заранее искать эквивалент, например, в контейнере закешированных строк, чтобы не плодить копии. В то же время, владение (ownership), распространяется на память, которую они занимают, но если нас устраивает хорошая "средняя температура по палате", то владельцем памяти назначается само приложение или сэндбокс.

Однако, для mutable данных всё иначе. Есть модальность, время. И эта модальность приходит через владельца. Владелец промежуточного массива внутри алгоритма - тот фрейм стека, на котором он создаётся. Владелец редактируемого документа - контейнер документов, тоже связанный с каким-либо фреймом в инициализации приложения. Для кнопки пользовательского интерфейса владельцем может быть окно или система GUI. Но только "или", не "и".

Любые изменяемые данные, вне зависимости от того, представляют они внешний ресурс (файл, соединение, ...) или внутреннее состояние, могут иметь альтернативные пути доступа, но только одного владельца. Если владельцев больше - получится doublethink, несовместимые модальности и серьёзная архитектурная ошибка, с последствиями которой приходится бороться.

Такие проблемы хорошо решать системой типов (но аккуратно, иначе фобии-и-Хаскель). Практический бонус - из массивных mutable данных с известным временем жизни можно делать регионы для immutable. В комментариях приветствуются ссылки на papers по теме раздельного управления памятью для mutable и immutable данных.