Wierd behavior of gc.collect

[Bodhi]

Thanks for the info.
I now suspect that the free lists are taking up the memory which won't be released unless we do a collect. I'm verifying that.

On Tuesday, March 19, 2013 10:43:11 PM UTC+5:30, Dave Angel wrote:
> On 03/19/2013 12:36 PM, Bodhi wrote:
> 
> > I know this, but my question is what does gc.collect do which results in the c library to free memory? Usually it is because of unreferenced objects in a cycle or something, but here that doesn't seem to be the case.
> 
> >
> 
> 
> 
> As I said, python calls the C free() function, whether it's when an 
> 
> object's ref-count goes to zero, or whether it's during a gc call, where 
> 
> circular refs are freed.
> 
> 
> 
> But free() does not necessarily release the memory to the OS.  And the 
> 
> times it does depends on which C library is being used, and what OS it's 
> 
> running on.
> 
> 
> 
> If the freed memory affects top in some situations, it's a C library 
> 
> detail.  I've written a replacement C allocator in the past for Windows 
> 
> that used a different scheme for blocks over a certain threshold, and 
> 
> when those blocks were freed, it gave them back to the OS.  But such 
> 
> blocks were multiples of 64k, which was the increment for VirtualAlloc.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> DaveA