Всем привет! Хотел народ активизировать, поскольку (Влад уже очертил), существует баг утечки памяти при работе в интеграции с Visual Studio 2010, на больших проектах он проявляется, что память постепенно растет 1 гб, 1.5, 2 и выше. Вещь довольно серьезная и нехорошая, я лазию в ClrProfiler и ищу утечки, хорошо бы чтобы и остальной народ подналег на исправление этого бага, обидно за интеграцию перед глобальным сообществом. У кого нет ClrProfiler его можно скачать здесь: здесь
Здравствуйте, CodingUnit, Вы писали:
CU>Всем привет! Хотел народ активизировать, поскольку (Влад уже очертил), существует баг утечки памяти при работе в интеграции с Visual Studio 2010
Он не столько в итеграции, сколько в движке. Я этот баг в интеграции SharpDevelop ловил, к сожалению так и не поймал.
Здравствуйте, hardcase, Вы писали:
H>Здравствуйте, CodingUnit, Вы писали:
CU>>Всем привет! Хотел народ активизировать, поскольку (Влад уже очертил), существует баг утечки памяти при работе в интеграции с Visual Studio 2010
H>Он не столько в итеграции, сколько в движке. Я этот баг в интеграции SharpDevelop ловил, к сожалению так и не поймал.
Видимо когда компилятором собирается проект это не заметно, но когда работает режим постоянного обновления дерева, то тут возникает утечка, может быть какие то структуры не правильно очищаются при каждой бекграундной компиляции, или что то накапливается, я смотрю там очень сильно много накапливается кэш типов, тысячи TypeBuilder, TypeInfoCache, TFunHeader десятки тысяч в сумме они дают сотни мегабайт, интересно этот кэш очищается где нибудь, и есть ли предел что он может кэшировать?
Здравствуйте, CodingUnit, Вы писали: H>>Он не столько в итеграции, сколько в движке. Я этот баг в интеграции SharpDevelop ловил, к сожалению так и не поймал.
CU>Видимо когда компилятором собирается проект это не заметно, но когда работает режим постоянного обновления дерева, то тут возникает утечка, может быть какие то структуры не правильно очищаются при каждой бекграундной компиляции, или что то накапливается, я смотрю там очень сильно много накапливается кэш типов, тысячи TypeBuilder, TypeInfoCache, TFunHeader десятки тысяч в сумме они дают сотни мегабайт, интересно этот кэш очищается где нибудь, и есть ли предел что он может кэшировать?
Прежде всего спасибо тебе, что написал про clrprofiler, я о нем до этого не знал.
Почитал здесь, как оно вообще работает.
Может упомянутые тобой объекты страдают от проблемы
и потому не освобождаются GC?
Здравствуйте, CodingUnit, Вы писали:
CU>Всем привет! Хотел народ активизировать, поскольку (Влад уже очертил), существует баг утечки памяти при работе в интеграции с Visual Studio 2010, на больших проектах он проявляется, что память постепенно растет 1 гб, 1.5, 2 и выше. Вещь довольно серьезная и нехорошая, я лазию в ClrProfiler и ищу утечки, хорошо бы чтобы и остальной народ подналег на исправление этого бага, обидно за интеграцию перед глобальным сообществом. У кого нет ClrProfiler его можно скачать здесь: CU>здесь
Я тоже помучился с этим ClrProfiler и ничего хорошего не нашел. Есть подозрение, что где-то кэшируются TypeBuilder-ы, но это вилами по воде писано.
По тому нужно, видимо, забывать про все супер-тулы и начинать использовать наши методы.
Течь (100%) идет во время пресоздания дерева типов проекта. Воспроизвоидится очень просто. Открываем проект интеграции (Nemerle\snippets\VS2010\Nemerle.Compiler.Utils\Nemerle.Compiler.Utils.nproj), заменяем любой модификатор доступа на другой (по фигу что менять, главное, чтобы изменялось что-то вне тела метода) и ждем пока в командной строке не появится надпись о том, что дерево типов перестроено. В процессе этого и некоторое время после этого наблюдается отчетливое пожирание памяти.
Функция в которой это происходит находится в Nemerle\snippets\VS2010\Nemerle.Compiler.Utils\Nemerle.Completion2\Engine\BackgroundWorks\Engine-BuildTypeTree.n:
По уму нужно подцеплять к основным объектам систему слежения которая бы позволила бы выявить повисающие объекты.
Можно сделать это с помощью макроса. Например, с помощью макроса уровня сборки добавить массив слабых ссылок на объекты некоторого типа и в их конструкторы заложить добавление элементов в этот массив. Далее в BuildTypesTree нужно добавить:
1. Сбор информации о том какие объекты были живы до выполнения тела метода.
2. Сборку мусора в конце тела (вроде уже есть) и дождаться ее завершения.
3. Отчет о том какие объекты данного типа не были собраны в процессе сборки мусора. Тут все просто. Это будет разница между старым и новым списком слабых ссылок.
То что используются слабые ссылки предотвратит удержание объектов этими сылками.
Ну, и далее нужно подвергнуть такому анализу объекты разных типов. Начать лучше с TypeBuilder-ов.
Следующий этап сложнее. На нем нужно будет определить что удерживает подвисающие объекты. Тут, возможно, поможет ClrProfiler.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>...Ну, и далее нужно подвергнуть такому анализу объекты разных типов. Начать лучше с TypeBuilder-ов.
VD>Следующий этап сложнее. На нем нужно будет определить что удерживает подвисающие объекты. Тут, возможно, поможет ClrProfiler.
Да, забыл добавить, что у меня со временем не здорово, так что если кто-то взялся бы за эту задачу и поймал бы утечку, то ему была бы честь и хвала.
Возьмется кто-нить?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CodingUnit, Вы писали:
CU>>Всем привет! Хотел народ активизировать, поскольку (Влад уже очертил), существует баг утечки памяти при работе в интеграции с Visual Studio 2010, на больших проектах он проявляется, что память постепенно растет 1 гб, 1.5, 2 и выше. Вещь довольно серьезная и нехорошая, я лазию в ClrProfiler и ищу утечки, хорошо бы чтобы и остальной народ подналег на исправление этого бага, обидно за интеграцию перед глобальным сообществом. У кого нет ClrProfiler его можно скачать здесь: CU>>здесь
VD>Я тоже помучился с этим ClrProfiler и ничего хорошего не нашел. Есть подозрение, что где-то кэшируются TypeBuilder-ы, но это вилами по воде писано.
Мне все же неясен алгоритм перестройки дерева, может ли он что то постоянно накапливать или дерево должно быть 100% таким же как и после предыдущего прохода компилятора если ничего не было изменено?
Если не должно изменяться то найти довольно просто, надо посмотреть разницу что появилось и что осталось и не удалилось, но у меня есть подозрение что именно идет накопление, NamespaceTree разрастается после каждой компиляции, тогда отчет будет неоднозначным, как же оно должно быть?
VD>По уму нужно подцеплять к основным объектам систему слежения которая бы позволила бы выявить повисающие объекты.
VD>Можно сделать это с помощью макроса. Например, с помощью макроса уровня сборки добавить массив слабых ссылок на объекты некоторого типа и в их конструкторы заложить добавление элементов в этот массив. Далее в BuildTypesTree нужно добавить: VD>1. Сбор информации о том какие объекты были живы до выполнения тела метода. VD>2. Сборку мусора в конце тела (вроде уже есть) и дождаться ее завершения. VD>3. Отчет о том какие объекты данного типа не были собраны в процессе сборки мусора. Тут все просто. Это будет разница между старым и новым списком слабых ссылок.
VD>То что используются слабые ссылки предотвратит удержание объектов этими сылками.
VD>Ну, и далее нужно подвергнуть такому анализу объекты разных типов. Начать лучше с TypeBuilder-ов.
VD>Следующий этап сложнее. На нем нужно будет определить что удерживает подвисающие объекты. Тут, возможно, поможет ClrProfiler.
Я могу начать с последнего этапа, думаю немало информации можно получить с помощью него...
Здравствуйте, YF, Вы писали:
YF>Прежде всего спасибо тебе, что написал про clrprofiler, я о нем до этого не знал.
пожалуйста, пользуйся на здоровье
YF>Почитал здесь, как оно вообще работает. YF>Может упомянутые тобой объекты страдают от проблемы YF>и потому не освобождаются GC?
Да есть такой распространенный род утечки, я надеюсь его не допустили в интеграции, по крайней мере то что я смотрел вроде сделано правильно.
Здравствуйте, CodingUnit, Вы писали:
VD>>Следующий этап сложнее. На нем нужно будет определить что удерживает подвисающие объекты. Тут, возможно, поможет ClrProfiler.
CU>Я могу начать с последнего этапа, думаю немало информации можно получить с помощью него...
А какой смысл с последнего то? Сначала нужно понять что течет, а потом уже где.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CodingUnit, Вы писали:
CU>Всем привет! Хотел народ активизировать, поскольку (Влад уже очертил), существует баг утечки памяти при работе в интеграции с Visual Studio 2010, на больших проектах он проявляется, что память постепенно растет 1 гб, 1.5, 2 и выше. Вещь довольно серьезная и нехорошая, я лазию в ClrProfiler и ищу утечки, хорошо бы чтобы и остальной народ подналег на исправление этого бага, обидно за интеграцию перед глобальным сообществом. У кого нет ClrProfiler его можно скачать здесь: CU>здесь
Одну утечку вроде исправил. Просьба потестировать. Похоже есть еще утечки.
Баг был в реализации макроса Record. Там была прикольная хэштаблица в которую складывались все тайпбидеры и мемберы в которых применялся атрибут RecordIgnore.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
