ANN: Stackless Python 0.2

[Gary Duzan]

Toby J Sargeant wrote:
> 
> On Mon, Jun 28, 1999 at 12:34:48AM -0400, Tim Peters wrote:
> > Nope!  It's a beauty of the implementation already that each code object
> > knows exactly how much "Python stack space" it needs, and (just) that much
> > is allocated directly into the code object's runtime frame object.  IOW,
> > there isn't "a Python stack" as such, so there's nothing to change here --
> > the stack is implicit in the way frames link up to each other.
> 
> This might be completely irrelevant, but during the course of my masters, I
> considered doing this kind of thing to java in order to allow asynchronous
> threads to share stack frames (don't ask...). My supervisor complained bitterly
> on the grounds that function invocations where orders of magnitude more
> common than object creation, and hence associating memory
> allocation/deallocation with every call was considered horrendously
> inefficient.

   This appears to be the conventional wisdom. The optimization class I
took used an ML-like language, and the first thing we did was to move
heap frames, which was the default, to the stack (i.e. closure
optimization.)
It might be less of an issue in an interpreted language if it already has
heap
allocation (or other sorts of) overhead to deal with when making calls.
There may be other allocation tricks which can be used, as well.

> It seems that this should affect Stackless Python equally as much. Does anyone
> have anything to add on the subject? I would imagine that frames could be
> allocated and managed in chunks to alleviate a lot of the memory management
> load...

   I would think that as well (at least at first.) Maybe pools of different
sizes of frame to limit the space overhead.

> Toby.

					Gary Duzan
					GTE Laboratories