[pypy-svn] r58227 - pypy/build/doc

fijal at codespeak.net fijal at codespeak.net
Thu Sep 18 18:16:43 CEST 2008


Author: fijal
Date: Thu Sep 18 18:16:42 2008
New Revision: 58227

Modified:
   pypy/build/doc/benchmark_memory_gcnotes.txt
Log:
A couple of notes and FAQ why M&S is so bad.


Modified: pypy/build/doc/benchmark_memory_gcnotes.txt
==============================================================================
--- pypy/build/doc/benchmark_memory_gcnotes.txt	(original)
+++ pypy/build/doc/benchmark_memory_gcnotes.txt	Thu Sep 18 18:16:42 2008
@@ -23,4 +23,29 @@
 
 * Garbage collector without paging: http://www.cs.umass.edu/~emery/pubs/f034-hertz.pdf, some discussion: http://lambda-the-ultimate.org/node/2391
 
+NOTE: this gc requires modest (600 LOC) support from operating system
+      *very* unlikely we can make such assumptions
+
 * paper about measurments http://www-cs.canisius.edu/~hertzm/thesis.pdf
+
+FAQ
+===
+
+Why mark&sweep is consuming so much memory on some benchmarks?
+--------------------------------------------------------------
+
+It seems that some allocation schemes (unfortunately ones happen to be
+found in pypy during normal operation) create very long free lists for small
+objects. Consider example:
+
+  [(i,) for i in range(amount)]
+
+in CPython, any immediate object created during list construction is immediately
+discarded. On the other hand, while creating the same thing in RPython, for
+each allocated space, it gets stored in free list of obmalloc or C library
+until collection happens. This means that since collection happens not
+very often (due to high costs), this gets accumulated (also for different
+python-level operations, different freelists will be populated, if requested
+size is different enough). If we invoke gc.collect
+every couple iterations (say 100 or 1000), this effect is gone. On the other
+hand it's becoming very very slow as a side effect.



More information about the Pypy-commit mailing list