Kevin Ryde <[EMAIL PROTECTED]> writes: > In guile 1.6.1 or the cvs on a recent i386 debian, I noticed that > doing a display of a weak key hash table can seemingly prevent a key > from being garbage collected. For instance > > (define h (make-weak-key-hash-table 7)) > > (define k "mykey") > (hash-set! h (string-copy k) 12345) > > (display (hash-ref h k)) (newline) > (display h) (newline) > (gc) > (display (hash-ref h k)) (newline) > > run with "guile -s foo.scm" produces > > 12345 > #wh(() () () () () ((mykey . 12345)) ()) > 12345 > > whereas I might have expected the gc to have collected the entry just > set, making the second hash-ref give #f rather than 12345. This is > what happens if the (display h) is not present.
And if you keep (display h) but add (display <some deep list-structure>), hash-ref will give #f again. The reason is that in order to avoid infinite loops due to circular data-structures print functions need to keep track of printed references. These are stored in a "print-state" attached to the port. After displaying h, the print-state contains the reference to the pair (mykey . 12345) which protects it from GC. We should probably replace this vector with a weak vector, or (perhaps more efficient) clear the references from the vector. > I don't really know if this is a bug, or ignorance on my part, but it > seemed more than a little strange. Well, it's not really a bug. The Guile GC doesn't make any guarantees that objects will get GC:d. For example, if the C stack happens to contain an integer which happens to coincide with a reference on the heap, that object won't get GC:d. A conservative GC only behaves nicely in a statisticial sense. Thanks for your observation. Best regards, Mikael Djurfeldt _______________________________________________ Bug-guile mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-guile
