анти GC. как?
 

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

если GC косит, то альтернативы храненения ссылок? Object ? Dictionary?

Ссылки на них в массиве как раз таки и хранятся.

ну собственно да, ссылка есть в массиве так что не покосит

Меня вообще всегда удивляли люди, которые относились к GC как к лохнесскому чудовищу.
Вроде всё работет, всё хорошо... И тут GC своими кальмаровыми усами съели что-то крайне важное.
Запомните: пока Вы можете достучаться до объекта ЛЮБЫМ способом - он не умрёт. )

Хотя, разве что исключение может быть ENTER_FRAME в удаленном объекте, который бы дёргал статический сеттер. Но опять таки, это объект до Вас стучится, а не Вы до объекта.

пойду убеждать свою параною, что все ок )

GC это так понял - чистка мусора ? Замечательная вещь. Не знаете почему нельзя удалять/очищать память от ненужных обьектов вручную ?

Потому что в этом вся соль.

Psycho Tiger
Ваше 4 тысячное сообщение, поздровляю :) А в чём соль то ?

Странно что нету никакой возможности самому полностью выгрузить обьект из памяти. Сиди жди пока гц вылезет из берлоги и сожрёт.

Не понял. Подробностей хочется.

Если зануллить везде объект, то считайте, что выгрузили из памяти. Зачем в AS3 вообще руками из памяти выгружать? AS3 не работает напрямую с памятью, следовательно и методов выгрузить из нее что-либо нет.
Если какие-то проблемы - воспользуйтесь профайлером.

Ну это давняя история. Были-жили сишники, ассеблерники и прочие люди. И работали они с памятью напрямую. Но пришли нонконформисты и сказали - это неудобно! Мы сделаем так, что машина сама решит когда пришло время что-то сделать с памятью! И сделали. Да так сделали, что кроссплатформенно получилось. С тех пор разделились языки на 2 категории: одни с GC, другие без. Мы - CLI Ecma-based язык. Мы не можем работать с памятью напрямую. Во всяком случае из AS )

Ну, жил был объект - потомок DisplayObject`а. Повесил на него очень умный программист ENTER_FRAME, да ещё как повесил - обработчик дёргал BigClass.someMethod, куда передавал себя аргументом. А тот что-то с ним творил. Например, брал с него какие-то данные. А потом пришел GC и перестал вызываться этот метод. Потому что объект удалился. Вот так вот объект подготовленный ко смерти стучался туда, куда GC не доберется.

Забыл добавить, что потом этот "программист" "потерял" ссылку на вот этот вот объект, в результате чего, тот остался на растерзание GC. А в оставшееся время до часа Х, отчаянно передавал ссылку на себя в BigClass.someMethod. )))

Дада, тонувший не умел плавать, но кричал команде спасателей )

Все же доп. средства управления GC не помешали бы. Например, мне очень хочется ставить GC на паузу, ему ведь пофиг, что щас отработать, что через минуту. А то этот умник частенько решает все почистить и затормозить именно в тот момент, когда каждая миллисекунда на счету (сложная 3D схема).

Так то да. Думаю, в будущем что-то похожее получим.
Сперва - почти официальный запуск GC через Loder#unloadAndStop, потом опкоды для жарки прямо в память. Whats next? )

Искал когда-то тоже информацию по GC, и нашёл способ принудительного вызова
В оригинале выглядит примерно так
Но без вызова System.gc() (который должен работать вроде как только в air) тоже работает

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

В примере с try-catch и без трупов работает :)

Кто-то, вроде silin, если память не изменяет, предлагал грузить пустой gif из byteArray-я. У него на эту тему класс есть. При этом вызывается gc без трупов и прочих извратов.

Добавлено через 3 минуты
Вот, нашел

Ага. Суть в том, что после Loader#unloadAndStop GC запускается. silin просто сразу обернул пустую gif`ку и отдавал её Loader`у, после чего выгружал.

Вообще-то это тоже изврат.

И насчёт мусора (это пожалуй лучше звучит чем трупы). Голодный и злой GC может не дождаться пока мы закончим валить в его пещеру мусор. Он выйдет, приберётся, а сверх прибранного мы насыплем ещё. Таким образом лишний мусор будет лежать до следующей уборки.

я смотрю кроме прямого контроля над GC все остальное - изврат.

и вообще топик ушел в русло "как бы дать GC еще поспать" )

Есть 2 проблемы: GC вызывается слишком часто и где то пропущена ссылка, что GC что-то не ест.

Вам есть разница сколько фп ест памяти - 120 мб или 125, когда у Вас её 4 гигабайта, 3 из которых в данный момент свободны?

кстати - о птичках..

насколько я понимаю больше 2 гигов юзать флэшплееру нельзя..это конфигурируемо?

вот полезная статья
для когото все это не ново , а комуто будет интересно

Сомнительный пункт про WeakReference.as. Так и не понял практической пользы.
Либо храним и помним где храним, а потом своевременно удаляем.
Либо кодер страдает ранним склерозом и пишет полную кашу, которую сам потом не может расхлебать.
Как-то так )

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

вот так я на нее и повелся!
спасибо что разъяснили

к статье надо было коменты прочитать. да и на этом форуме форуме эту чудо-статью не раз обкладывали.