[ZODB-Dev] sticky objects

[Tim Peters]

[Jeremy Hylton]
> ...
> How are you measuring memory?  Python is not returned

"returning"?

> memory to the OS,

As reported earlier, it does on my box.  Python allocates memory for "large"
strings via the platform malloc(), not via Python's small-object allocator.
So all the string memory here is also returned to the platform C's free().
Of course Python has no control (or even influence) over what the platform C
does with it.

> so any os-level tool like top or ps will report the high water mark for
> the process (200MB) rather than what is currently allocated.

It might be interesting for Simon, on his system, to stick the guts of his
program in a loop.  If the platform C isn't able to return memory to the OS,
then at least the high water mark shouldn't go up much across outermost-loop
iterations.

> It might be more useful to call something like cacheExtremeDetail()
> (method on the DB object).

If I change the tail end of Simon's program to do:

  raw_input( 'enter to invalidate all' )

  ## got rid of the _p_invalidate calls

  print len(db.cacheExtremeDetail())  # new line
  connection.cacheMinimize()
  print len(db.cacheExtremeDetail())  # new line

  # Memory = 200 Mb
  raw_input( 'enter to quit' )

then the first new line prints 20002, and the second prints 3.  The 3
remaining are all ghosts, and didn't go away completely because they're
still referenced (the root object; the PersistentList still bound to `data`;
and a PItem instance still bound to `item` (left over from the last "for
item in data:" loop).