Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, _LeShik, Вы писали:

C>>>Тут две проблемы:
C>>>1) Фрагментация кучи.
C>>>2) Циклические ссылки.
_LS>>Большая просьба, если есть какие нибудь доки по этой теме, либо можешь словами объяснить поподробнее что к чему буду очень благодарен.
C>Словами... В общем, первая проблема достаточно простая — если мы создаём и удаляем много объектов, то в непрерывных блоках памяти, которые используются для распределения этих объектов, у нас могут появляться "дырки".

Как я понимаю, ввиду отсутсвия javaScript API для работы с памятью, никак повлиять на это я как девелопер не могу. Т.е. получается что в случае если IE аллоцирует память и после этого освобождает не всю то всё что можно сделать — пенять на браузер.

C>Вторая проблема — сложнее. Все GUI-объекты и узлы DOM в IE представлены как COM-объекты. А в COM-е используется подсчёт ссылок. И если сделать цикл из объектов, использующих подсчёт ссылок, то они будут жить вечно.

C>Это очень известная проблема: http://msdn.microsoft.com/en-us/library/bb250448.aspx , http://foohack.com/2007/06/msie-memory-leaks/ и вообще поищи по словам "reference counting IE memory leak".

Да много читал об этой проблемме, но есть довольно сильное подозрение что это не циклические ссылки. Во первых в тестовом приложении не было ничего что может вызвать такие проблеммы, ни native функций, ни Listener-ов, не работаем с DOM напрямую (через DOM, Document классы), а GWT клятвенно обещает что их компоненты не текут (по причине циклических ссылок) http://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks . ДА и ни sIEve ни Microsoft Js memory leak detector не находят никаких элементов с циклическими сылками.

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