[movitz-devel] Re: The reactions of gc to hard-drive reads

[Frode Vatvedt Fjeld]

Elliott <ejohnson at kvpt.org> writes:

> I got movtiz/losp/tmp/harddisk.lisp to function phyically here on an
> old pentium-mmx 166.  Hats off to Peter Minten!

This is really nice to hear. I haven't gotten around to play with
harddisk.lisp myelf yet.

> ";; Handling out-of-memory exception ..
>  Error: Scanning an infant object #x55e23 at #x3eaff (end #x3eb0c)" 

This problem I believe I've identified and fixed. If I haven't checked
it in already (don't remember), I´ll do it tomorrow (I'm slightly
wasted at the moment).

> ";; Handling out-of-memory exception..  ;; Old space: 255.6 KB, new
> space: 255.6 KB, freed: 0 KB"

There's a 256 KB heap limitation in los0 (i.e. los0-gc) currently
that's probably the root of this (actually the "freed: 0 KB" part is a
clear indication that somethign isn't working well, as the GC wasn't
able to free anything). You want to stay well below this limit, right
now. I'm in the process of re-designing some of the low-level
structures that are the source of this problem, though. Hopefully
it'll be fixed shortly.

> Another situation concering gc and the harddisk.lisp file is the
> length of these vectors.  I havn't tested this with writes, because
> it requires makeing a vector larger than 62 sectors, but when using
> the command (hd-read-sectors 0 0 63) I get another exception, this
> one with INIT::CLUMPS which seems to be part of los0-gc.lisp.  Here
> is the exception:
>
> "Error: The value of INIT::CLUMPS, #x3f01, is not of type (INTEGER
> #x0 #x3e80)."

When you get errors like this, try to get a backtrace (using the
function muerte:backtrace or the top-level :bt, and report the output.
If ":bt" fails for one reason or another, try ":bt :spartant t", which
will print each stack-frame's argument more safely.

Specifically, that error is due to my assuming that one won't want to
allocate 16000 clumps (one clump is equal to two words, or eight
bytes, so 63 sectors is just above this limit, see los0-gc.lisp) in
one go. This limitation is probably too small for serious work, but
for simple experimentation it might be ok.. or not? So fix los0-gc.


Thanks Elliott for the reports!

-- 
Frode Vatvedt Fjeld