Page 2 of 2

Re: Heap limit

Posted: Wed Dec 07, 2016 9:06 am
by Robert
dmaksimiuk wrote:2. When the garbage collector should claim all the memory back? ...
... the environment still showed allocated memory around 670_000_000 bytes.
The environment - I guess you mean the status bar at the bottom - is sometimes slow to show released memory. I don't know if calling Kernel.Collect is delayed, or if reporting the result is delayed. But it can take a few unrelated trivial actions (like moving a Window) before this happens; unloading the module is not necessary.

I don't think there is a problem here as the memory is released when necessary. See, for example, the DoMany command in my previous post where all the memory is automatically released 100 times within the FOR loop.

Re: Heap limit

Posted: Wed Dec 07, 2016 8:29 pm
by dmaksimiuk
Hi Robert,
Yes, I meant the status bar at the bottom. I ran your program, and on my machine I got on average 58 to 61 blobs allocated (61 for a single mode). It seems that the garbage collect does the job between runs, and heap into at the bottom is not updated immediately.

Still, the reason for such a diversity in memory allocation between different Windows machines cannot be explained.

Cheers,
Darek

Re: Heap limit

Posted: Wed Dec 07, 2016 8:47 pm
by Robert
dmaksimiuk wrote:Still, the reason for such a diversity in memory allocation between different Windows machines cannot be explained.
My theory that it is an incompatibility with another program can be checked in principal; Do a clean Windows install and keep testing the memory allocation as you replace your other software until the problem occurs.
But:
- That is a lot of work
- Even if you find it is an incompatibility with programme "Xyz" does not explain exactly what that problem is, or how to solve it
- I do think this is a serious problem, not just a curiosity.