Re: [MIT-Scheme-devel] Cleaning weak hash tables in secondary GC daemon?

[Matt Birkholz]

> From: Alexey Radul <address@hidden>
> Date: Wed, 14 Sep 2011 20:21:48 +0100
> 
> [...]
> 
> Stupid question: why would rehashing the table be bad?

>From the comments in runtime/gcdemn.scm:

 ;;; PRIMITIVE-GC-DAEMONS are executed during the GC.  They must not
 ;;; allocate any storage and they must be prepared to run at times
 ;;; when many data structures are not consistent.

A peek at hash.scm confirms that rehashing a hash table is one of
those "inconsistent data structures" times.  The rehash-all-gc-daemon
procedure is on the PRIMITIVE-gc-daemons list.

> From: Taylor R Campbell <address@hidden>
> Date: Wed, 14 Sep 2011 18:42:52 +0000
>
> [...]
> Working around this probably requires implementing a deferred-rehash
> mechanism.  Not conceptually difficult, but it would take a bit of
> work.

Let's make with the semaphores already!  I think SOME hash table
lookeruppers (and rehashinators) should grab the table's (new)
semaphore before traipsing through its buckets...

> [...] a very good description of the storage-reclamation value of
> cleaning a weak hash table.  Speaking of which, when are secondary
> GC daemons run?

I found the answer was up to me -- my application.  I added a call to
trigger-secondary-gc-daemons! in my gtk-thread, running it there after
an arbitrary number of GCs.

> From: address@hidden (Matt Birkholz)
> Date: Sun, 12 Dec 2010 22:30:40 -0700
> 
> [...]
> 
> You might notice that, after a day or two of spinning The One, your
> free space will have noticeably shrunk.  I thought I had a memory leak
> somewhere, but then I happened to (trigger-secondary-gc-daemons!) and
> all my heap came back!

Yours in Scheme,
-Friar Puck