Re: The reactions of gc to hard-drive reads
Frode Vatvedt Fjeld <[email protected]> Wed, 16 Jun 2004 00:54:51 +0200
| Newsgroups | gmane.lisp.movitz.devel |
|---|---|
| Message-ID | <[email protected]> |
Elliott <[email protected]> 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