Posted Fri, 09 Sep 2016 11:42:33 GMT in reply to
Jack Applegame
On Mon, 05 Sep 2016 09:37:20 GMT, Jack Applegame wrote:
Our project actively uses tasks. At the same time are about a thousand tasks. Memory consumption significantly exceeds the expected values. And I can't find the reasons.
I noticed that many (but not all) of the objects continue to exist and not be collected by the GC even if there is not a single reference to them. Even after forcing by GC.collect().
As far as I know vibe.d does not destroy the terminated task/fibers, but "caches" them for reuse.
Can the references to the objects to hang in the "cached" task stack or somewhere else? And how to fight with such references?
There are mainly two possible places for references:
The fiber's stack. This, AFAIK, should be no issue, because the GC recognizes the stack pointer of the fiber, and the used part of the stack should be clear of any application references at the end of the task callback. Could make sense to forward this part to a GC implementation expert, though.
Task local storage. This is explicitly cleared/destroyed after the the task callback finishes.
I can't think of anything else in the low level system that could be responsible right now. Unfortunately, the results of DMD's -vgc (dub -b profile-gc) are not ideal for debugging this sort of issue (it's cumulative instead of printing the remaining memory allocations at exit), but it might give a hint of possible sources.
