koobas.hobune.stream
Unity2019.2.1f1 Heap Memory leak
At ios platform,when alloc a huge buffer like: var bytes = new bytes[100 1024 1024]; bytes = null; GC.Collect(); Runtime momery increase 100M,and couldn't decrease
Please check Memory usage with the Memory Profiler instead of a system monitor. Those monitors only display what they can see from the outside. However, Unity does not reduce Memory pool sizes, including that of the managed heap, even though it does reduce the usage of these pools (the Memory Profiler would show usage and reserved pool sizes).
Another way to test this would be to validate that you can allocate another array of the same size without increasing the apps memory footprint (if no further allocations happened). Which would also mean it's not a leak.
That said, if you do find a memory leak, please report it using the menu entry "Help -> Report A Bug" instead to make sure it doesn't get lost and can be fixed.
Thanks for reply. (1).At the IOS platform with il2cpp, can't managed heap reserved sizes be released and back to os? If alloc a large memory,even though the useage memory has gc correctly,do the reseved memory pool still remain the large sizes? (2).In a function, repeatly alloc buffers 10$$anonymous$$ 20$$anonymous$$ ... 90$$anonymous$$ 100$$anonymous$$ incrementally like: var bytes1 = new bytes[10 1024 1024]; var bytes2 = new bytes[20 1024 1024]; ... var bytes10 = new bytes[100 1024 1024]; The total memory size increase 100$$anonymous$$. But on the contrary,alloc 100$$anonymous$$ 90$$anonymous$$ ...20$$anonymous$$ 10$$anonymous$$, memory increase190$$anonymous$$. Does the memory pool work correctly? (3).If i create a $$anonymous$$emoryStream,and keep writing about 100$$anonymous$$ data at a time.When the size of $$anonymous$$emoryStream grown to 200$$anonymous$$,the reserved memory increase to 1.4G. So app runs at Iphone6s crash because of memory. This happend in Unity2019.2.1, and will not happen in Unity2017.4.1. Is this a bug for Unity?
(1) The managed heap is a non-compacting, non-moving garbage collected heap. So fragmentation could keep pages from being released. Also, requesting new memory from the OS takes time. So Unity does not release managed memory pools ever. Native ones can get released eventually, might differ from platform to platform though.
(2) you'd want to make sure that the memory of the previous allocation has been fully collected with no new allocations in between that could have fragmented the memory so that there is not enough space to fit the 100$$anonymous$$ alloc into the 90$$anonymous$$ alloc whole. also see this API since requesting a GC.Collect does not actually enforce that GC is run right there and then but might just schedule it.
(3) Sounds more like a difference between C# versions/Scripting Back-end versions but I can't answer this definitively here (maybe try the forums, or $$anonymous$$ono Repos). $$anonymous$$emoryStream might have some caching memory behind it that could cause this and then that could be a change introduced by $$anonymous$$icrosoft's implementation to which $$anonymous$$ono has to keep binary compatibility.
I believe I have run into the same issue on iOS. In my case I am serializing a large amount of data via Json.NET. If I try to serialize through a memorystream then memory usage goes over a gb and is never released. If I run it twice I get an app crash. The only way I can get it to work is to serialize into a StreamWriter writing to a file.
