Утечки памяти в 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# с открытым исходным кодом в последнем пункте), но, возможно, это может помочь вам найти источник утечки или доказать, что это действительно утечка памяти.

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

Тони

Answer 2

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