I've been working on my Z-Machine interpreter library again. It basically started as a project to turn Frotz into a Ruby extension (Frotz, probably the most po

I've been working on my Z-Machine interpreter library again. It basically started as a project to turn Frotz into a Ruby extension (Frotz, probably the most popular interpreter, is written in C). The code has undergone quite a few transformations now. Frotz uses a lot of static memory -- it's basically setup to run a single zcode program at a time. Which makes sense, of course. For my library, I wanted to be able to run more than one program (or multiple copies of the same program) at the same time. So, I basically rewrote the core of Frotz. All the memory for a Z-Machine is broken up into structs which are passed around. There were some fun memory management issues related to running multiple programs. The typical zcode program consists mostly of static memory (lots and lots of strings and code), so that static memory can be shared between programs. I have a test where I load something like 100,000 copies of minizork into memory and the process size "only" jumps to 118MB. Of course, normal code doesn't need that many simultaneous Z-Machine instances so garbage collection keeps memory pretty reasonable. Last time I worked on dorothy, I setup a demo webapp here: http://ifrotz.org http://ifrotz.org Which illustrates why I wanted to be able to run multiple programs. The demo runs minizork, dynamic memory is dumped and restored between requests. The hints, exits, and history feature is possible because the server "listens in" on your game and the games others have played. Lately I've been working on more memory inspection stuff, and now I have to work on some of the unfinished Z-Machine features (I've only implemented the v3 screen model). The code is on Github: http://github.com/eki/dorothy/tree/master http://github.com/eki/dorothy/tree/master