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

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

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

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

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

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

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

Надеюсь, что так или иначе поможет?

Тони

Ответ 2

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