Я не буду вызывать, он сам =). wxvxw об этом и писал:
Не во время, конечно, но после конца стека вызовов есть шанс, что GC сработает, потому что он так решит, что вызовет лаг.

Psycho Tiger, пока все дейсвия в стэке не завершаться GC не запутится. а между стэками ... ну вызовется и вызовется. это его работа =) и причём тут лаг? лаг возникает как раз тогда, когда выгружать надо килограммы памяти. а не копейки.

Ну да, прав. Хотя если по событию вроде MOUSE_MOVE "всплывать" событие и постоянно теребить мышкой - в принципе можно эти килограммы памяти и получить. Один хрен смотреть надо по ситуации.

Вообще я никогда не сталкивался с проблемой GC, проблему нафантазировал с подачи wxvxw чтобы в будущем знать, что делать. Видимо, проблема высосана из пальца. Спасибо.

Ну, почти отмазался =)

А толку мазаться? Если я в каких-то суждениях заблуждаюсь и мне об этом говорят - это очень хорошо.

Psycho Tiger, чего? от чего там появятся килограммы памяти? сейчас они у вас появляются от того, что Вы мышкой теребите? если Вы думаете, что event.clone вызывается постоянно, даже если нету слушателя, то Вы глубоко заблуждаетесь. это было бы просто глупо. и если бы было так, то GC был бы Вашим лучшим другом, Вы бы с ним не расставались.

А какая разница когда? от того, что лаг будет не сию секунду, а через полсекунды тебе легче станет? Лаг то все равно будет.
И да, GC вполне может включится если будет много событий диспатчится и соответственно удалятся - от чего бы не включится, их же кто-то должен убирать?
Т.е. традиционно, большую часть времени занимает отрисовка (а не наши банальные скрипты), но если изза сборщика мусора ты не успел к плановому апдейту - ты увидишь лаг, т.е. если в это время играет какая-то анимация, то она тормознет.
Да и вообще, не об этом была речь, даже если предположить, что сборщик мусора работает очень быстро, то вполне есть шанс, что в определенной ситуации можно придумать решение которое будет более еффективным чем "точный" хиттест который должен сделать плеер, чтобы определить диспатчить ли событие кому-то или нет. Как я уже говорил, если хиттестить надо квадратики, или заведомо не пересекающиеся фигуры или круги, то тут просто напрашивается не подписываться на всплытие, а выявление цели (целей) использовав упрощенный алгоритм.

Да, wvxvw сказал сейчас примерно мои мысли =)

BlooDHounD, насколько мне известно GC не убирается по мелочам, она ленива. Пусть минуту не будет лага, но потом когда события наплодят килограмм она включится лаг будет.

Вообще уже считаю что разговор идёт в тупик. Надо всегда смотреть по ситуации и не иметь шаблонов в голове.

Олег, я могу тебя расстроить. ссылки на локальные переменные удаляются сразу же. без всяких GC. так что от тупой генерации событий GC не запуститься.
Psycho Tiger, уу-к. покажи мне этого сферического коня в вакууме.

А при чем тут теплое с мягким? Представь, что событие в памяти не занимает место кратное 8, 256 или 1024 или не знаю, как там у нас память распеделяется - это значит, что память будет фрагментироваться не зависимо от того, когда именно ты удалил объект, а самая большая нагрузка - это не вычистить, а переназначить / дефрагментировать память. Т.е. забить массив нулями это одно, а найти части массива, которые бы можно было поместить между другими частями займет гораздо больше циклов. Кроме того, речь вообще о другом.

GC умеет дефрагментировать память? Где об этом можно подробнее узнать?

Нет, это не задача GC, но эти процессы не могуть быть не связаны, т.как если GC высвобождает память, то если у нас все объекты не одинакового размера, то рано или поздно наступит момент, когда количество "дырок" т.е. неиспользуемых участков памяти будет очень большим. Легче всего это представить, как тетрис :) GC это когда вы заполнили ряд, a фрагментация, это когда в ряду остались "дырки".
Я чесно не знаю, как именно флеш дефрагментирует свою память, но если бы он этого не делал вообще, то любая флешка запущенная долгое время отъедала бы все больше и больше ресурсов. И в итоге флеш не любили бы еще больше :)

wvxvw, а зачем делать то, что ты описываешь? есть специальные блоки памяти, под разные объекты. локальные переменные хранить не надо. и у удалять не особо надо. можно поверх писать и не парится. всё равно к ним повторного обращения не будет.

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

Добавлено через 3 минуты
именно поэтому, кстати, наблюдается постепенный рост используемой памяти.

Я вообще про другое...
Т.как я не особо силен в этом вопросе, и то, как именно плеер распоряжается своей памятью покрыто мраком, я бы наверное почитал вот это:
http://msdn.microsoft.com/en-us/magazine/bb985010.aspx
Скажем так, вряд ли человечество придумало что-то радикально новое и не похожее. Возможно, что в плеере эти проблемы решаются по-другому, но они все-равно должны как то решаться. Можно еще погуглить про Яву молодое поколение vs старшее поколение, в Яве как-то этот вопрос более освещен, потому что на ней есть много серверов, где за память нужно очень усердно бороться :)

Если наблюдается постоянный рост памяти - то это плохо :( Но, как бы это по-моему не впервой такое с плеером... как бы не привыкать.

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

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

Смотри, я не говорю, что у нас должно быть один-в-один с .NET, но по духу и по принципу работы AVMPlus это игрушечная копия CLR, т.е. скорее всего, что у нас все проще, и финализация не имеет к нам никакого отношения, но принципиально должно быть похоже. В Яве примерно тоже так...

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