[pypy-commit] pypy default: Improve

fijal noreply at buildbot.pypy.org
Sat Jun 4 10:05:55 CEST 2011


Author: Maciej Fijalkowski <fijall at gmail.com>
Branch: 
Changeset: r44691:23e4b5da5cfe
Date: 2011-06-04 10:04 +0200
http://bitbucket.org/pypy/pypy/changeset/23e4b5da5cfe/

Log:	Improve

diff --git a/pypy/doc/project-ideas.rst b/pypy/doc/project-ideas.rst
--- a/pypy/doc/project-ideas.rst
+++ b/pypy/doc/project-ideas.rst
@@ -11,6 +11,9 @@
 `mailing list`_. This is simply for the reason that small possible projects
 tend to change very rapidly.
 
+XXX: write a paragraph that this is a loose collection and where to go
+from here
+
 Numpy improvements
 ------------------
 
@@ -23,8 +26,6 @@
 
 * interface with fortran/C libraries.
 
-Potential mentors: fijal
-
 JIT tooling
 -----------
 
@@ -35,18 +36,47 @@
 Work on some of other languages
 -------------------------------
 
-xxx
+There are various languages implemented using the RPython translation toolchain.
+One of the most interesting is the `JavaScript implementation`_, but there
+are others like scheme or prolog. An interesting project would be to improve
+the jittability of those or to experiment with various optimizations.
 
 Various GCs
 -----------
 
-xxx
+PyPy has pluggable garbage collection policy. This means that various garbage
+collectors can be written for specialized purposes, or even various
+experiments can be done for the general purpose. Examples
+
+* An incremental garbage collector that has specified maximal pause times,
+  crucial for games
+
+* A garbage collector that compact memory better for mobile devices
+
+* A concurrent garbage collector (a lot of work)
 
 Remove the GIL
 --------------
 
-xxx
+This is a major task that requiers lots of thinking. However, few subprojects
+can be potentially specified, unless a better plan can be thought out:
+
+* A thread-aware garbage collector
+
+* Better RPython primitives for dealing with concurrency
+
+* JIT passes to remove locks on objects
+
+* (maybe) implement locking in Python interpreter
+
+Experiment (again) with LLVM backend for RPython compilation
+------------------------------------------------------------
+
+We already tried working with LLVM and at the time, LLVM was not mature enough
+for our needs. It's possible that this has changed, reviving the LLVM backend
+(or writing new from scratch) for static compilation would be a good project.
 
 .. _`issue tracker`: ...
 .. _`mailing list`: ...
 .. _`jitvirwer`: ...
+.. _`JavaScript implementation`: ...


More information about the pypy-commit mailing list