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

I>>А в дотнет в этом месте утечки в принципе невозможны.

AV>И что? Можем спокойно получить в другом.

В другом, но в ряде мест, где на раз происходят в С++, в дотнет просто невозможно чему утечь.

При чем это очень сильно облегчает жизнь разработчикам.


I>>Я объяснил как можно получить утечку в с++, не надо никаких глобальных присваиваний и тд и тд — достаточно передать параматры в метод.

AV>И что? Да, можно получить утечку. С этим никто не спорит. В так любимом тобой дотнете нету утечек? Есть. Только получаются иначе. А упование на то, что GC сам все соберет часто приводит к плачевным результатам.

Дело не в том, что получается иначе. Дело в том, насколько просто заполучить эту утечку.

Т.е. интересует вероятность и фактор зависимости от кривых рук.

В дотнет эти оба показателя гораздо ниже, чем в с++.

I>>Покажи внятно, где я неправ, если можешь.

AV>Если не упираться в использование голых указателей, то все деструкторы прекрасно вызовутся сами.

Обратно не факт Деструкторы могут спокойно себе не вызваться и это еще одна особенность с++.

Это ж очевидные вещи.

I>>Не валяй дурака — показывай код, как будут утекать строчки. В с++ обычное исключение может подвесить целый вагон строчек и мелких объектов в памяти.

AV>Вот тебе псевдокод.

AV>MyClass o=new MyClass();
AV>o.strProp = "xxx";
AV>longLiveObj.myEvent += new XXXEvent(o.Method);
AV>o=null;

AV>И куда же делась наша строчка?

Во первых, мы говорили про отсутствие такого рода присваиваний.

Во вторых это _не_ утечка. Это ссылка, которую держит longLiveObj.myEvent

Здесь "утекание" явное и по другому ты не сможешь сделать.

В с++ утекание неявное из за того, что
1. есть необходимость передавать динамику по указателю и на 100% этого избежать нельзя
2. деструктор может и не вызваться в ряде случаев из за ошибочного кода

В дотнет ничего подобного быть не может в принципе.

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

I>Вот касательно твоего хипа, как он выдержт такое — память выделяетяс мелкими объектами под завязку, т.е. где о 1.5-1.8 гб, а потом где то половина-две трети освобождается и выделяется память объектами большего размера обратно под завязку.
А давай сперва в GC навыделяем под завязку кучу объектов по мегабайту, потом каждый второй освободим и навыделяем объектов по 32 байта опять под завязку. Сдохнет ведь. Потому как LOH не уплотняется.

I>вот qh это срубает наповал потому что там пул на размер объекта. А у тебя как будет ?
А хрен его знает, я не помню уже. Надо сурс искать. Вообще там зоны есть, которые могут быть вообще отданы назад системе если всё что там проаллоцировано было освобождено.

I>Дотнетовский вполне прилично справляется. Единсвенная проблема может возникнуть, если объекты более 10 мб или долгоживущие, в последнем поколении, их gc не двигает.
Вооот. GC не панацея

I>P.S. Говорят, если ИТ забанить на форуме, то он напишет два раза больше отличных статей
Интересно, а что будет если забанить например тебя? Может статью напишешь.

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


E__>>Ну, объективно говоря, получить утечку в дотнете или жабе сильно сложнее.

AV>Да, такие утечки как на плюсах там либо не получить, либо получить очень сложно. С этим глупо спорить. Но другие виды утечек встречаются достаточно часто. Особенно часто это происходит из-за излишних надежд на GC.

В смысле, надеяться на то, что GC обладает телепатией, и сам сам догадается, какие из объектов в коллекции нужны программеру, а какие нет?

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

I>Ну ка, дай мне ссылку. Только не забудь показать как ты посчитал, проверм твою арифметику. Я вот помню что дотнетом занялся задолго до того, как женился, а женился в начале 2003го и периодически работал на двух работах, одна с++, вторая — дотнет, при том три года как не пользую с++.

Да, признаю. Вспомнил фразу не так.

I>>>Писали в т.ч. и на с++ и не мало.

AV>>И? Это никак не означает, что эта ниша для С++. Это делали скорее от безысходности.

I>Это сейчас так очевидно. А тогда сиплюсники орали точь в точь как ты сейчас.

Именно С++ и именно ASP? Ты точно помнишь? Или ты про COM-объекты, которые потом могли использоваться из ASP?

I>>>цитирую "Смотришь, сколько всего потерял — вычитаешь. Сколько нового получил — прибавляешь."

AV>>Паша, использование ActiveX никак не означает, что веб является нишей для плюсов. Так что то, что он оттуда ушел еще ничего не значит. Особенно в ракурсе того, что в данной подветке первоначально речь шла про сервера.

I>Ранее являлся. Писали — значит была такая ниша. Перестали — значит вытеснили.

Писали. От безысходности. Как-то только появилось что-то что могло заменить быстренько перестали (за очень редким исключением). А вот на серверах чего-то такого не наблюдается.

I>А первоначально речь шла про геймдев, ан е про сервера. Просто кое кому было удобно спрыгнуть на сервера в контексте ММО.

Паша, про то на чем пишутся серверные приложения первым завел речь ты, в ответе CreatorCray.
Вот тебе линк на твое сообщение — http://rsdn.ru/forum/Message.aspx?mid=3625288&only=1

Автор: Ikemefula
Дата: 03.12.09

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

CC>>>Хорошо, убедил, ТЕБЕ на С++ писать мучительно больно и трудно. Сплошные непонятки и трудности.
I>>Мне было нормально. Мне на любом языке нормально пишется.
F>... как на фортране?. :3
А что у ВАс имеется против фортрана?
Я вот в своей нише смотрю так где-то Fortran — 50%, С/С++ (хотя ++ тут не к месту) — 50%, С# — 0%

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


AV>Паша. Перечитай следующее предложение медленно, вдумываясь в каждое слово. Ты сравнил кол-во моделей с памятью 2+ ГБ и кол-вом моделей с памятью 2+ ГБ плюс кол-во моделей с памятью менее 2 Гб.

разумеется. если 2+ это 16 страниц, а 2- 18, это значит что меньше 2 гб ты вряд ли найдешь что либо серьезное, о чем я тебе и сообщаю.

AV>ак ты предлагаешь на основе твоих данных сравнить кол-во моделей с памятью 2+ и 4+ Гб?

А при чем здесь 4+ ?

ты снова забыл с чего начиналось "Сейчас 2 гб брать уже несерьезно, даже дешовые ноуты идут с 3-4гб памяти, но гарантировано 2 и выше."

вникни с выделеное.

I>>Потому что их нельзя сравнить с обычнымкомпоп. А полноценный ноут, даже деск-, — можно

AV>Далеко не каждый ноут тоже можно сравить с компом. А некоторые нетбуки сравнимы и с номальными ноутами.

Примеры в студию по каждому предложению на моделях 2008-2009.

I>>Не понял что значит "GC по умолчанию нет", где его нет ?

AV>В плюсах.

Разумеется, я знаю. Это значит что добавляй ядро, не добавляй, перформанс не изменится.

А в нете GC работает в отдельном потомоке и сли GC не серверный а конкурентный, то будет работать паралельно с главным потоком и графы объектов подлежащих освобождению будет выявлять паралельно. Иногда, конечно, будут останавливатьяс все потоки, но крайне редко, например из за мега хитрых финалайзеров.
Я привел сылку на статью, вроде внятно написано.
В итоге алг. который пользует много динамики, очень сильно зависит от стратегии распределения памяти и далеко не всегда этот расклад в пользу с++ хипа.

I>>Фетиш никто не делает. Я говорил про GC в контексте управления памяти. От тебя требуется рассказать, как наличие доп. ядра процессора скажется на работе дотнет приложения и нативного. Предположим, для простоты, специально многопроцессорность не планировалась.

AV>Брать абстрактные приложения? Ничего сказать нельзя.

Не надо абстрактных. Я привел сылку статью, нужно взять да проанализировать кривые.

А кром освобождения есть еще и выделение, это тоже стоит учесть — дотнетовское распределение уступат только особо хитрым хипам и стеку.

для достижения такого же эффекта на с++ придется пахать и пахать.

AV>Да, кстати, о каком GC ты говоришь? А то разные ведут себя по разному. Да и от поколения еще зависит.

Разумется.

I>>Да ладно. Хороший аллокатор да еще и универсальный это очнь сложно.

AV>И это конечно подымает планку аж на всем проекте.

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

I>>было бы это просто, в операторе new что по дефолту, был бы другой код.

AV>Потому что тот универсальный аллокатор в подавляющем количестве случае более чем достаточен. И только когда его не хватает, то делают свой, который заточен под конкретную задачу.

Потому что универсальный и многопоточный написать крайне сложно.

Оптимизации аллокации в с++ себя исчерпали. А вот в GC задел на будущее огромный.

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

CC>>>>Хорошо, убедил, ТЕБЕ на С++ писать мучительно больно и трудно. Сплошные непонятки и трудности.
I>>>Мне было нормально. Мне на любом языке нормально пишется.
F>>... как на фортране?. :3
A>А что у ВАс имеется против фортрана?
A>Я вот в своей нише смотрю так где-то Fortran — 50%, С/С++ (хотя ++ тут не к месту) — 50%, С# — 0%

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

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

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

I>>Есть статья про сравнение хипа и GC
I>>http://rsdn.ru/article/dotnet/GC.xml

Автор(ы): Чистяков Влад (VladD2)
Дата: 14.06.2006
Уже много сказано слов о том, что такое GC, чем он хорош и как лучше его применять. Но, наверно, очень многим хочется знать, как устроен конкретный GC. Данная статья открывает некоторые подробности устройчтва GC в .NET Framework.

CC>Про GC краткое описание принципов работы вижу, а где сравнение?

сравнение было по второй ссылке.

I>>Можно начать отсюда. Выложить алгоритмы к сожалению не могу.
CC>Нет, теоретические "А победит Б" не интересуют. Нужно то, что можно проверить практически.

Не интересуют — не пиши в КСВ.

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

I>>Вот касательно твоего хипа, как он выдержт такое — память выделяетяс мелкими объектами под завязку, т.е. где о 1.5-1.8 гб, а потом где то половина-две трети освобождается и выделяется память объектами большего размера обратно под завязку.
CC>А давай сперва в GC навыделяем под завязку кучу объектов по мегабайту, потом каждый второй освободим и навыделяем объектов по 32 байта опять под завязку. Сдохнет ведь. Потому как LOH не уплотняется.

По мегабайту — издохнет.

I>>вот qh это срубает наповал потому что там пул на размер объекта. А у тебя как будет ?
CC>А хрен его знает, я не помню уже. Надо сурс искать. Вообще там зоны есть, которые могут быть вообще отданы назад системе если всё что там проаллоцировано было освобождено.

В том то и дело, что не все.

I>>Дотнетовский вполне прилично справляется. Единсвенная проблема может возникнуть, если объекты более 10 мб или долгоживущие, в последнем поколении, их gc не двигает.
CC>Вооот. GC не панацея

Я узнал это где то на подходе к 2003му.

I>>P.S. Говорят, если ИТ забанить на форуме, то он напишет два раза больше отличных статей
CC>Интересно, а что будет если забанить например тебя? Может статью напишешь.

Меня неколько раз банили на год. Не помогло.

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

E__>>>Ну, объективно говоря, получить утечку в дотнете или жабе сильно сложнее.

AV>>Да, такие утечки как на плюсах там либо не получить, либо получить очень сложно. С этим глупо спорить. Но другие виды утечек встречаются достаточно часто. Особенно часто это происходит из-за излишних надежд на GC.

E__>В смысле, надеяться на то, что GC обладает телепатией, и сам сам догадается, какие из объектов в коллекции нужны программеру, а какие нет?

Почти. Забывают, что некоторые ссылки в других местах все таки остались.

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

I>>>А в дотнет в этом месте утечки в принципе невозможны.

AV>>И что? Можем спокойно получить в другом.

I>В другом, но в ряде мест, где на раз происходят в С++, в дотнет просто невозможно чему утечь.

И что? С++ в одном месте, в донете в другом. Мне как-то не станет легче, кто в дотнете в другом месте получили утечку.


I>>>Я объяснил как можно получить утечку в с++, не надо никаких глобальных присваиваний и тд и тд — достаточно передать параматры в метод.

AV>>И что? Да, можно получить утечку. С этим никто не спорит. В так любимом тобой дотнете нету утечек? Есть. Только получаются иначе. А упование на то, что GC сам все соберет часто приводит к плачевным результатам.

I>Дело не в том, что получается иначе. Дело в том, насколько просто заполучить эту утечку.

Забыть вовремя отписаться очень сложно?

I>>>Покажи внятно, где я неправ, если можешь.

AV>>Если не упираться в использование голых указателей, то все деструкторы прекрасно вызовутся сами.

I>Обратно не факт Деструкторы могут спокойно себе не вызваться и это еще одна особенность с++.

Можно пример когда в корректно написанном коде деструктор не вызовется?

I>>>Не валяй дурака — показывай код, как будут утекать строчки. В с++ обычное исключение может подвесить целый вагон строчек и мелких объектов в памяти.

AV>>Вот тебе псевдокод.

AV>>MyClass o=new MyClass();
AV>>o.strProp = "xxx";
AV>>longLiveObj.myEvent += new XXXEvent(o.Method);
AV>>o=null;

AV>>И куда же делась наша строчка?

I>Во первых, мы говорили про отсутствие такого рода присваиваний.

I>Во вторых это _не_ утечка. Это ссылка, которую держит longLiveObj.myEvent

А что это такое? Если к этой ссылке ты никаким образом добраться не можешь? От того, что ссылка где-то там болтается лечге не станет.

I>Здесь "утекание" явное и по другому ты не сможешь сделать.

I>В с++ утекание неявное из за того, что
I>1. есть необходимость передавать динамику по указателю и на 100% этого избежать нельзя

И? Никто не мешает тебе не использовать голые указатели. А получать их там где они только необходимы.

I>2. деструктор может и не вызваться в ряде случаев из за ошибочного кода

Пример можно увидеть?

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

I>Оптимизации аллокации в с++ себя исчерпали. А вот в GC задел на будущее огромный.

любопытно, за счёт чего?.

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

I>>>вот qh это срубает наповал потому что там пул на размер объекта. А у тебя как будет ?
CC>>А хрен его знает, я не помню уже. Надо сурс искать. Вообще там зоны есть, которые могут быть вообще отданы назад системе если всё что там проаллоцировано было освобождено.
I>В том то и дело, что не все.
Да ты похоже лучше меня знаешь что у меня там в коде написано

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

I>Кроме того, не ясно, как нативный с++ обснуётся на новых сегментах, вроде браузрного ПО, типа Сильверлайт тот же .

Ну если у гугла получится на хромиум много народа подсадить — то запросто обоснуется, через ихний native client. А Сильверлайт тогда соответственно сольет, в силу слабой кроссплатформенности.

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

I>>Это сейчас так очевидно. А тогда сиплюсники орали точь в точь как ты сейчас.

AV>Именно С++ и именно ASP? Ты точно помнишь? Или ты про COM-объекты, которые потом могли использоваться из ASP?

И про COM тоже. Шота сиплюсные комиков сильно поубавилось.

I>>Ранее являлся. Писали — значит была такая ниша. Перестали — значит вытеснили.

AV>Писали. От безысходности. Как-то только появилось что-то что могло заменить быстренько перестали (за очень редким исключением). А вот на серверах чего-то такого не наблюдается.

Про убиение речь не идет. Речь идет о местах 1..3

I>>А первоначально речь шла про геймдев, ан е про сервера. Просто кое кому было удобно спрыгнуть на сервера в контексте ММО.

AV>Паша, про то на чем пишутся серверные приложения первым завел речь ты, в ответе CreatorCray.
AV>Вот тебе линк на твое сообщение — http://rsdn.ru/forum/Message.aspx?mid=3625288&only=1

Автор: Ikemefula
Дата: 03.12.09

Не подскажешь, кто же это такой спросил про ММО ?

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

AV>>>Вытеснила из ниши интернет-магазинов и подобного?

I>>Интернет-магазины это уже давно не джава.

E__>А там когда-то была жаба? Насколько я знаю, из-за специфики(много магазинов на одном хостинге + небольшая загрузка каждого) там прочно укоренились php, perl и прочие интерпритируемые скрипты, работающие по принципу "получил запрос"-"загрузил"-"выполнил"-"забыл(выгрузил)". Ни плюсы, ни шарп, ни жава для таких вещей не годятся.

А вот у google app engine среди поддерживаемых языков — php и JSP. И магазины там вполне можно хостить

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

AV>>Паша. Перечитай следующее предложение медленно, вдумываясь в каждое слово. Ты сравнил кол-во моделей с памятью 2+ ГБ и кол-вом моделей с памятью 2+ ГБ плюс кол-во моделей с памятью менее 2 Гб.

I>разумеется. если 2+ это 16 страниц, а 2- 18, это значит что меньше 2 гб ты вряд ли найдешь что либо серьезное, о чем я тебе и сообщаю.

То что сейчас уже мало выпускается ноутов с менее чем 2 Гб памяти? Паша, Америки ты для меня не открыл.

AV>>ак ты предлагаешь на основе твоих данных сравнить кол-во моделей с памятью 2+ и 4+ Гб?

I>А при чем здесь 4+ ?

I>ты снова забыл с чего начиналось "Сейчас 2 гб брать уже несерьезно, даже дешовые ноуты идут с 3-4гб памяти, но гарантировано 2 и выше."

I>вникни с выделеное.

Вот только ноутов с 4+ по сравнению с 2+ гораздо меньше.

I>>>Потому что их нельзя сравнить с обычнымкомпоп. А полноценный ноут, даже деск-, — можно

AV>>Далеко не каждый ноут тоже можно сравить с компом. А некоторые нетбуки сравнимы и с номальными ноутами.

I>Примеры в студию по каждому предложению на моделях 2008-2009.

Тебе нетбуки не нравятся. Тебе и показывать чем они плохи. Дерзай.

I>>>Не понял что значит "GC по умолчанию нет", где его нет ?

AV>>В плюсах.

I>Разумеется, я знаю.

И зачем же ты в таком случае задаешь абсолютно бессмысленные вопросы?

I>Это значит что добавляй ядро, не добавляй, перформанс не изменится.

А вот это уже далеко не так уж и верно. Кстати, ты сильно увидишь своими глазами, что GC работает на другом процессоре?

I>В итоге алг. который пользует много динамики, очень сильно зависит от стратегии распределения памяти и далеко не всегда этот расклад в пользу с++ хипа.

Ты опять забыл написать "в пользу аллокатора по-умолчанию".

I>>>Фетиш никто не делает. Я говорил про GC в контексте управления памяти. От тебя требуется рассказать, как наличие доп. ядра процессора скажется на работе дотнет приложения и нативного. Предположим, для простоты, специально многопроцессорность не планировалась.

AV>>Брать абстрактные приложения? Ничего сказать нельзя.

I>Не надо абстрактных. Я привел сылку статью, нужно взять да проанализировать кривые.

И? Если в моем приложении хватает стандартного аллокатора с запасом, то мне все равно, что он может работать быстрее. Если же скорости не хватает, то можно заняться и специально заточенным.

I>для достижения такого же эффекта на с++ придется пахать и пахать.



AV>>Да, кстати, о каком GC ты говоришь? А то разные ведут себя по разному. Да и от поколения еще зависит.

I>Разумется.

То есть взять вот так и огульно ответить нельзя?

I>>>Да ладно. Хороший аллокатор да еще и универсальный это очнь сложно.

AV>>И это конечно подымает планку аж на всем проекте.

I>Да, существенно. В с++ от этого нельзя абстрагироваться. Все девелоперы должны хорошо и четко знать, что происходит с памятью и какие где издержки.

Зачем остальным это нужно?

I>>>было бы это просто, в операторе new что по дефолту, был бы другой код.

AV>>Потому что тот универсальный аллокатор в подавляющем количестве случае более чем достаточен. И только когда его не хватает, то делают свой, который заточен под конкретную задачу.

I>Потому что универсальный и многопоточный написать крайне сложно.

А он нужен? Всем подряд. Или в большинстве случае достаточно и того, что имеется? Сделать можно много чего. Вот только эти усилия можно потратить более продуктивно.

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

AV>>>И что? Можем спокойно получить в другом.

I>>В другом, но в ряде мест, где на раз происходят в С++, в дотнет просто невозможно чему утечь.

AV>И что? С++ в одном месте, в донете в другом. Мне как-то не станет легче, кто в дотнете в другом месте получили утечку.

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

как часто ты пользуешь класы с деструкторыми и как часто ты передаешь параметры в функцю ?

AV>>>И что? Да, можно получить утечку. С этим никто не спорит. В так любимом тобой дотнете нету утечек? Есть. Только получаются иначе. А упование на то, что GC сам все соберет часто приводит к плачевным результатам.

I>>Дело не в том, что получается иначе. Дело в том, насколько просто заполучить эту утечку.

AV>Забыть вовремя отписаться очень сложно?

Ошибки в параметрах, исключениях и деструкторах гораздо чаще случаются, примерно на порядок-два.

I>>Обратно не факт Деструкторы могут спокойно себе не вызваться и это еще одна особенность с++.

AV>Можно пример когда в корректно написанном коде деструктор не вызовется?

Ты гарантируешь что вся программа написана корректно ? Ну ты и фантазёр.

Теоретически, если господь бог будет писать на с++, то все деструкторы будут вызываться.

Это единственный случай. Ну еще программки вроде хелловорлд.

AV>>>И куда же делась наша строчка?

I>>Во первых, мы говорили про отсутствие такого рода присваиваний.

I>>Во вторых это _не_ утечка. Это ссылка, которую держит longLiveObj.myEvent

AV>А что это такое? Если к этой ссылке ты никаким образом добраться не можешь? От того, что ссылка где-то там болтается лечге не станет.

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

I>>В с++ утекание неявное из за того, что
I>>1. есть необходимость передавать динамику по указателю и на 100% этого избежать нельзя

AV>И? Никто не мешает тебе не использовать голые указатели. А получать их там где они только необходимы.

Я говорю безотносительно голых указателей. Любая динамика это потенциально проблемы.

Смартпоинтеры не спасут тебя на 100%


I>>2. деструктор может и не вызваться в ряде случаев из за ошибочного кода

AV>Пример можно увидеть?

1 из за исключений SEH
2 деструктор не объявлен как виртуальный,
3 проезд по памяти и повреждение стека
4 кривая работа с шаблонами, см. п 2
5 неправильное завершение потока
6 неправильная работа с объектами со счетчиком ссылок

это навскидку, можно подумать и найти еще случаи.

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

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

I>>Оптимизации аллокации в с++ себя исчерпали. А вот в GC задел на будущее огромный.

F>любопытно, за счёт чего?.

Этих коллекторов тыщи, я просто сумлеваюсь что найден оптимальный. И даже в дотнете он постоянно меняется.

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

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

I>>>>вот qh это срубает наповал потому что там пул на размер объекта. А у тебя как будет ?
CC>>>А хрен его знает, я не помню уже. Надо сурс искать. Вообще там зоны есть, которые могут быть вообще отданы назад системе если всё что там проаллоцировано было освобождено.
I>>В том то и дело, что не все.
CC>Да ты похоже лучше меня знаешь что у меня там в коде написано

Я ж тебе пример привёл. Там точно ясно, что все освобождаться не будет, токмо часть. При чем здесь твой код ?