[pypy-svn] r45007 - pypy/dist/pypy/doc/discussion
mwh at codespeak.net
mwh at codespeak.net
Fri Jul 13 11:29:03 CEST 2007
Author: mwh
Date: Fri Jul 13 11:29:02 2007
New Revision: 45007
Added:
pypy/dist/pypy/doc/discussion/emptying-the-malloc-zoo.txt (contents, props changed)
Log:
a half finished discussion document
Added: pypy/dist/pypy/doc/discussion/emptying-the-malloc-zoo.txt
==============================================================================
--- (empty file)
+++ pypy/dist/pypy/doc/discussion/emptying-the-malloc-zoo.txt Fri Jul 13 11:29:02 2007
@@ -0,0 +1,38 @@
+.. coding: utf-8
+
+Emptying the malloc zoo
+=======================
+
+Around the end-of-the-EU-project time there were two major areas of
+obscurity in the memory management area:
+
+ 1. The confusing set of operations that the low-level backend are
+ expected to implement.
+
+ 2. The related, but slightly different, confusion of the various
+ "flavours" of malloc: what's the difference between
+ lltype.malloc(T, flavour='raw') and llmemory.raw_malloc(sizeof(T))?
+
+At the post-ep2007 sprint, Samuele and Michael attacked the first
+problem a bit: making the Boehm GC transformer only require three
+simple operations of the backend. This could be extending still
+further by having the gc transformer use rffi to insert calls to the
+relevant Boehm functions^Wmacros, and then the backend wouldn't need
+to know anything about Boehm at all (but... LLVM).
+
+A potential next step is to work out what we want the "llpython"
+interface to memory management to be.
+
+There are various use cases:
+
+**lltype.malloc(T) – T is a fixed-size GC container**
+
+ This is the default case. Non-pointers inside the allocated memory
+ will not be zeroed. The object will be managed by the GC, no
+ deallocation required.
+
+**lltype.malloc(T, zero=True) – T is a GC container**
+
+ As above, but all fields will be cleared.
+
+ - lltype.malloc(U, raw=True) –
More information about the Pypy-commit
mailing list