[pypy-svn] r56198 - pypy/extradoc/talk/ep2008

[fijal at codespeak.net]

Author: fijal
Date: Tue Jul  1 01:15:57 2008
New Revision: 56198

Modified:
   pypy/extradoc/talk/ep2008/gc.txt
Log:
Try to walk around this a bit, I still don't like it too much


Modified: pypy/extradoc/talk/ep2008/gc.txt
==============================================================================
--- pypy/extradoc/talk/ep2008/gc.txt	(original)
+++ pypy/extradoc/talk/ep2008/gc.txt	Tue Jul  1 01:15:57 2008
@@ -7,22 +7,63 @@
 * GC is *not* only the part that takes
   care of circular references
 
-...
-
 What is refcounting?
 ====================
 
-XXX explain
+* Store a field on each object which is a number
+  of references
+
+* Each time you play with it increase refcount
+
+* When refcount goes to 0, delete object
 
 What is a generational moving GC?
 =================================
 
-XXX explain
+XXX explain, probably few slides, quick:
+
+* Different generations of objects
+
+* Collection runs from roots to all objects
+
+* Young objects are kept in nursery
+
+* Older ones are moved away
+
+* Write barriers, old objects referencing young ones
 
 Difference in performance
 =========================
 
-XXX
+* no mutable fields on objects in generational
+ (cache friendly)
+
+* stuff moves around sometimes
+
+* assuming certain usecases (not many old objects referencing
+  young ones)
+
+Allocation cost
+================
+
+* refcounting/C malloc - expensive
+
+* generational gc - cheap
+
+Allocating large amount of objects
+==================================
+
+* CPython - O(n^2) where n is number of objects
+  allocated
+
+* Any reasonable generational GC should do better
+
+Collection costs
+================
+
+* Full collection - costly (always the case with cpython)
+
+* Nursery collection - quick
 
 Finalizers
 ==========
@@ -35,12 +76,33 @@
 Finalizers - resurrection
 =========================
 
-XXX
+* what happens if your __del__ puts reference back
+  to itself?
+
+* in CPython it can be called more than once
+
+* in other implementations, only once
 
 Finalizers - cycles with __del__
 ================================
 
-XXX
+* in CPython, they never get collected
+
+* interesting example - a module global with __del__
+
+* in PyPy, cycle gets broken in random order
+
+* no hacks like globals clearing
+
+When to call __del__?
+=====================
+
+* example open('x', 'w').write('stuff')
+
+* on refcounting, flushes file immediately
+
+* on any other gc, it might be deferred for
+  a while
 
 Calling C-level code
 ====================
@@ -49,33 +111,9 @@
 
 * Problems with write barriers
 
-...
-
 Strange operation costs
 =======================
 
 * id
 
 XXX what else?
-
-Allocation cost
-================
-
-* refcounting/C malloc - expensive
-
-* generational gc - cheap
-
-Allocating large amount of objects
-==================================
-
-* CPython - O(n^2) where n is number of objects
-  allocated
-
-* Any reasonable generational GC should do better
-
-Collection costs
-================
-
-* Full collection - costly (always the case with cpython)
-
-* Nursery collection - quick