Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 6

Какие интересные статьи попадаются в блоге Mail.ru, но стоит тебе только забыть где-то убрать «галочку» при установке любимого приложения — всё, неделю систему вычищать.
В данном конкретном случае интересная статья в toptal engineering blog, а в блоге мейл.ру всего лишь перевод. Не то, чтобы у мейла и своих интересных статей не было — бывали, скорее интересно, а не страшно ли им топтал рекламировать таким образом в том числе и среди своих сотрудников? :)
Отличная статья, спасибо!
Интересно было бы почитать про реальные способы локализации такого рода проблем. Сталкивался с возрастающим потреблением памяти процессами passenger'а и долго не мог понять с чего вообще начать поиски источника проблемы, помогло только сравнение с предыдущими билдами в которых такого замечено не было, а вот как локализовать проблему в целом приложении так и остается для меня загадкой.
Мне довольно странно в хорошей, в целом, статье ни разу не встретить ни упоминаний RValue, ни того, как руби хранит значения размером менее 23 байт (или 40, смотря как считать), ни слов «локальная куча» (ruby heap), ни рекомендаций, как избежать самой частой и легковозбудимой проблемы утечки: создания множества маленьких объектов, которые выделяются в локальной куче. Спойлер: память из локальной кучи в MRI _никогда_ не отдается обратно системе. Ну, вплоть до холодного рестарта MRI.
Но вопрос в целом имеет отношение ко всем языкам, использующим сборщики мусора.

Это неверно. Верная фраза: «Но вопрос в целом имеет отношение ко всем языкам, не использующим подсчет ссылок или управление областью видимости».


Если нараду с этим в языке используется или может использоваться еще и сборщик мусора (как в CPython или Rust), все равно в большинстве случаев подсчет ссылок освободит память к нужному моменту.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий