This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
A few days ago, I wrote to this list about a problem I was having with guile. In brief, I said: On Wed, Jan 27, 1999 at 10:34:13AM -0600, Jon Trowbridge wrote: > I've been using guile as a scripting language to control a large, > proprietary pieces of simulation software my company uses... > ... > However, I've started to run into a strange problem, which I'm > assuming is a bug in guile. Every now and then, the execution speed > of the scheme code drops dramatically. > ... > Other than suddenly becoming *very slow*, the system continues to work > as normal. Programs still execute and give the correct answers, if > given enough time to run. There is no external evidence of any data or > memory corruption. No segfaults occur. I've continued to explore the problem, and it appears to be tied to garbage collection. In my extended guile, I define and execute the following procedure: (define (loop) (execute-a-trivial-simulator-command) (display (gc-stats)) (newline) (loop)) The execute-a-trivial-simulator-command just constructs a smob-ified version of a small, simple C++ object and returns it... there is nothing fancy going on in that code, and it is small enough to carefully inspect for errors, buffer overflows, etc. --- which I have done. As far as I can discern, there is nothing dangerous or tricky in there. This works fine for a large number of iterations, until I get the following (I've broken up the lines and added whitespace to make the display less convoluted): ((gc-time-taken . 39) (cells-allocated . 98240) (cell-heap-size . 98304) (bytes-malloced . 138283) (gc-malloc-threshold . 225006) (cell-heap-segments (1077948424 . 1077686280) (1078485000 . 1077960712))) ((gc-time-taken . 39) (cells-allocated . 98278) (cell-heap-size . 98304) (bytes-malloced . 138367) (gc-malloc-threshold . 225006) (cell-heap-segments (1077948424 . 1077686280) (1078485000 . 1077960712))) ...so far, so good... ((gc-time-taken . 45) (cells-allocated . 41282) (cell-heap-size . 98304) (bytes-malloced . 4294925671) ***** Yikes! (gc-malloc-threshold . 2147421210) ***** Double Yikes! (cell-heap-segments (1077948424 . 1077686280) (1078485000 . 1077960712))) ((gc-time-taken . 87) (cells-allocated . 41284) (cell-heap-size . 98304) (bytes-malloced . 4294925645) (gc-malloc-threshold . 2147421171) (cell-heap-segments (1077948424 . 1077686280) (1078485000 . 1077960712))) ((gc-time-taken . 128) (cells-allocated . 41284) (cell-heap-size . 98304) (bytes-malloced . 4294925611) (gc-malloc-threshold . 2147421120) (cell-heap-segments (1077948424 . 1077686280) (1078485000 . 1077960712))) ((gc-time-taken . 170) (cells-allocated . 41284) (cell-heap-size . 98304) (bytes-malloced . 4294925577) (gc-malloc-threshold . 2147421069) (cell-heap-segments (1077948424 . 1077686280) (1078485000 . 1077960712))) Notice how when the bytes-malloced and gc-malloc-threshold suddenly get huge, the gc-time-taken starts going up by about 42 units per iteration. Letting the loop keep running, this value stays constant. When I run this test and get the slow-down effect, the change in gc-time-taken per iteration (after slow-down) is always constant... but it is a different value each time. It seems to range between 25-50. Also, this slow-down seems to be a one-shot affair... I can let the slowed-down loop run for a very long time, and the differences stay constant. BTW, if I terminate the loop with ctrl-c and get back into the shell, typing (gc) always returns immediately. But the execution of any scheme program (even simple ones that have nothing to do with my simulation extensions) is dramatically slowed down. Since this bug is all that stands between me and a state of pure scheme-hacking bliss, any suggestions or assistance would be greatly appreciated. -JT