Ben Goetter's unnecessarily apocalyptic weblog.

Fri, 07 Apr 2006

Progress to 1.3.1

I had hoped to release 1.3.1 today, but I'm tired and out of time. Instead I'll offer a brief status report of what has turned out to be the memory manager sub-release.

The D-S-W bug fell easily. Pocket Scheme has enormous conses (hmmm... that sounds a bit rude), a misfeature which I look forward to correcting in 2.0. I've been using what otherwise would be wasted padding space to track various attributes of different types: closed state of ports, read-only state of strings, various object ownership flags, even variable lookup address memoization. Since vectors and continuations didn't yet use that space, I now use it to track the additional state needed for marking a variable-sized node (per the Thorelli variant of D-S-W, q.v. Jones and Lins Garbage Collection, p. 84) With this change, the mark phase no longer recurses, and hence no longer blows the Scheme thread's runtime stack.

The objects that we're marking occupy three separate heaps: the cons heap, of fixed-sized cons cells; a vector heap, for storing strings and vectors; and a continuation heap, for saving pieces of the runtime stack that embody the current continuation. Prior to 1.3.1, only the cons heap adhered to the configured (Tools - Configure - Memory) size limit, with the other two heaps being allowed to grow without bound. Furthermore, on hibernation we would release memory from the cons heap, but would never do anything with the vector or continuation heaps. Hence a deeply recursing program could hog all of the device's memory, then would refuse to release it gracefully, eventually necessitating that the system kill pscheme. Like the D-S-W recursion bug, this is a problem that only became manifest in 1.2, when such deep recursion became possible through runtime stack juggling.

Anyway, Pocket Scheme now abides fully by the configured heap size limit, which specifies the sum of the limits of the three types of heap. Furthermore, it releases memory from the continuation heap much more aggressively than before. There is some fun new UI with slider bars to configure the three heaps' share, too. (Ideally, this would auto-configure as the program runs, but at present I need to know at startup the limit of each particular heap. In 2.0 we'll make these heaps two or three subsections of a single size-constrained area.) Since we're now trying to run three heaps out of the space formerly hosting just one, an advertised-as-1-megabyte heap offers less capacity than it once did. I've bumped the minimum default heap to 2 megs for now, and have made a note to look into our stack consumption at some point... the last time I looked at it carefully was in 1999, and that was on a MIPS device.

Two work items remain before I can release 1.3.1. Presently I accumulate data for the transcript window in a temporary file \Temp\Scheme Transcript.htm. On WM5, unlike previous releases, the entire filesystem is hosted in flash NVRAM, which is both relatively slow to write and has a limited number of writes in its lifetime. So in the interest of minimizing wear and tear to the PDA, I'm moving the transcript into a true RAM buffer (which is where the temporary file would have been hosted, pre WM5). Also, while in the garbage collector I noticed some dodgy assumptions about how we mark "extension" objects (e.g. the windows from w32, or the connections from tcp), which I need to review while GC is still paged into my mind, so to speak.

There's a lot of talk about the "2.0" vaporscheme in this entry. Partly driven by distaste of pscheme's current performance, partly as a procrastination tactic to avoid actually grovelling the pointer-reversing graph traversal code, I sat down and hacked out much of the object layout for the 2.0 release, reducing conses to 8 bytes apiece. I can't implement any of this until 2.0, however, because it depends on my reworking the evaluator extensively. Oh, speed the day.

posted at: 23:22 | path: /pscheme | permanent link to this entry


Run up the county road to the Sitts place just beyond Gate Creek and back. Felt sluggish at the start and didn't really want to run, so I took with me an Axim loaded with a CF of some Metallica - an old motivational tool of mine from a few years back that I stopped using after one surprise encounter with a bear on a trail encouraged me to pay more attention. I had forgotten how good "Am I Evil" (and its tempo changes) is for running.

posted at: 20:18 | path: /training | permanent link to this entry

Powered by blosxom.
Based on a true story.
Syndicate this, if you dare.
Copyright 2006, Ben Goetter. All rights reserved.