Форум Flasher.ru
Ближайшие курсы в Школе RealTime
Список интенсивных курсов: [см.]  
  
Специальные предложения: [см.]  
  
 
Блоги Правила Справка Пользователи Календарь Поиск рулит! Сообщения за день Все разделы прочитаны
 

Вернуться   Форум Flasher.ru > Блоги > inozemcev

Оценить эту запись

present - simple. Часть I. Контроль за ресурсами.

Запись от inozemcev размещена 17.11.2010 в 02:34
Обновил(-а) inozemcev 17.11.2010 в 15:54

Прежде всего немного вводной информации про garbage collector сборщик мусора.

Из статьи мы узнаем, что garbagecllector отрабатывает за нас контроль за динамической памятью и предупреждает нас от cледующих ошибок:

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

2. Утечки памяти

Создав объект в динамической памяти, программист может не удалить его после завершения использования. Если ссылающейся на объект переменной будет присвоено новое значение и на объект нет других ссылок, он становится программно-недоступным, но продолжает занимать память, поскольку команда его удаления не вызывалась. Такая ситуация и называется утечкой памяти. Если объекты, ссылки на которые теряются, создаются в программе постоянно, то утечка памяти проявляется в постепенном увеличении объёма используемой памяти; если программа работает долго, объём используемой ею памяти постоянно растёт и через какое-то время ощутимо замедляется работа системы (из-за необходимости при любом выделении памяти использовать своппинг), либо программа исчерпывает доступный объем адресного пространства и завершается с ошибкой.
Что же очень хорошо. Спасибо ему за это. Читаем дальше

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

Ввиду определенной сложности определить будет ли наш объект использоваться в будущем или нет, интерпретатор с которым мы имеем дело ориентируется на достижимость объекта.

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

Итак степень нашей ответственности за контролем над ресурсами сводится к тому, чтобы сделать наш отработанный объект недостижимым для системы.

Давайте, чтобы окончательно во всем разобраться, пользуясь все той же статьей дадим определение достижимости объекта:

Цитата:
Неформально можно задать следующее рекурсивное определение достижимого объекта:
  • определённое множество объектов считается достижимым изначально — корневые объекты, обычно в их число включают все глобальные переменные и объекты, на которые есть ссылки в стеке вызовов;
  • любой объект, на который есть ссылка из достижимого объекта тоже считается достижимым, за исключением ссылок указанных программистом как слабая.
Что такое корневой объект в контексте actioncript 3? Обратимся к Колину Муку:

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

Далее Колин Мук демонстрирует нам, как сделать объект недостижимым. (см главу 14 его подробного руководства) И тут же предупреждает нас, что следуя его советам он не гарантирует нам тем не менее реальное удаление объектов из памяти, ссылаясь на то, что на практике удаление объектов из памяти приводит к тормозам. (если кто знает как замерит эти тормоза буду очень признателен) И потому сборщик наш будет халтурить и делать свою работу циклически.

Стратегия удаления недостижимых объектов языка ActionScript называется сборкой мусора с использованием алгоритма поэтапных пометок и вычищений. Далее он пишет о том как это работает... завтра продолжим )))
Всего комментариев 3

Комментарии

Старый 22.11.2010 20:59 dimarik вне форума
dimarik
 
Аватар для dimarik
а финики-то, финики-то где в чем фабула? )
Старый 24.11.2010 15:55 inozemcev вне форума
inozemcev
 
Аватар для inozemcev
Чуть позже продолжу ... сейчас увлекся сборкой проекта Maven-ом в intellijIdea

Конечная цель написать свой профайлер на air, используя flash.samples и еще кое - что, и быть уверенным в том, что в проекте нет утечек.
Старый 27.11.2010 20:27 inozemcev вне форума
inozemcev
 
Аватар для inozemcev
Стратегия удаления недостижимых объектов языка ActionScript называется сборкой мусора с использованием алгоритма поэтапных пометок и вычищений. Далее он пишет о том как это работает:

Цитата:
После запуска среда Flash просит операционную систему оставить либо выделить произвольный (это слово мне совсем нравится, я бы хотел точно знать сколько, подозреваю эти параметром можно управлять на этапе компиляции, передавая его в config.xml, но пока не уверен), в которой будут хранится объекты выполняемой в настоящий момент программы. Теперь самое главное:

1. По мере выполнения программы объекты накапливаются в памяти. В любой момент времени некоторые объекты могут оказаться достижимыми, а другие недостижимыми (пригодными для сборки мусора).
(Этот тезис очень важен. Это ценная информация. Именно на ней мы и построим нашу систему учета и контроля над ресурсами)


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


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

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

 


Часовой пояс GMT +4, время: 23:30.


Copyright © 1999-2008 Flasher.ru. All rights reserved.
Работает на vBulletin®. Copyright ©2000 - 2024, Jelsoft Enterprises Ltd. Перевод: zCarot
Администрация сайта не несёт ответственности за любую предоставленную посетителями информацию. Подробнее см. Правила.