утечки памяти в Microsoft.FSharp.Control.Mailbox?

Question

Я сейчас нахожусь в поиске утечек памяти в длинном сервисе (использующем F #).Единственная «странная» вещь, которую я до сих пор видел, это следующее:

• Я использую MailboxProcessor в подсистеме с алгебраическим типом данных с именем QueueChannelCommands (более или менее куча команд Add / Get- некоторые с присоединенным AsyncReplyChannels *
• , когда я профилирую службу (используя Ants Memory Profiler), я вижу экземпляры массивов упомянутого типа (большинство имеют длину 4, но растут) - все пустые (нулевые), чьи ссылки кажутсябудет удерживаться Control.Mailbox:

Я не вижу никакой причины в моем коде для такого поведения (ваш стандартный код, который вы можете найти в каждом примере с почтовым ящиком - просто цикл сlet! = receive и последующий match заканчивались return! loop()

Кто-нибудь видел такое поведение раньше или даже знает, как с этим справиться? Или это даже (известная) ошибка?

Обновление: рост массивов действительно странный - кажется, что добавлено дополнительное пространство без правильного использования:

Answer 1

Я ни в коем случае не эксперт по F #, но, возможно, вы можете посмотреть на первый ответ в этой теме:

Есть ли в Async.StartChild утечка памяти?

В первом ответе упоминается руководство по профилированию памяти на следующей странице:

• http://moiraesoftware.com/blog/2011/12/11/fixing-a-hole/

Но они упоминают эту версию с открытым исходным кодом F #

• https://github.com/fsharp/fsharp/blob/master/src/fsharp/FSharp.Core/control.fs

И я не уверен, что это то, что вы ищете (об этой версии F # с открытым исходным кодом в последнем пункте), но, возможно, это может помочь вам найти источник утечки или доказать, что это действительно утечка памяти .

Надеюсь, что это может как-то помочь?

Tony

Answer 2

.NET имеет свой собственный сборщик мусора, который работает довольно хорошо. Наиболее распространенный способ вызвать утечки памяти в технологиях .NET - это создавать делегаты, а не удалять их в деконструкторах объектов.