[plt-scheme] v372: Uncollectable Scheme memory (even with sandbox.ss)

Over the past several years, we've been wrestling with a memory leak
in Halyard. This leak appears to occur in the Scheme heap, and we
haven't been able to control it using either custodians or sandboxes.

What we're trying to do:

 1) When the user selects "Reload script", we call kill-evaluator on
our current sandbox.
 2) We create a new sandboxed evaluator, and transfer control inside it.
 3) From inside the new evaluator, we perform a fresh 'require' of the
user's script.

What we want to happen:

  * All the memory used by the old sandbox should be collected by the GC.

What happens:

  * A sizable chunk of Scheme memory (on the order of 10-80MB) remains
permanently uncollectable.

You can see the relevant part of our loader code here:

http://iml.dartmouth.edu/git?p=halyard.git;a=blob;f=test/Runtime/halyard/loader/stage1.ss;h=b6e0809ac469da4dbbdb5253d8309a5326ef1749;hb=c73872e0efe79b1e5eff0ac44b6b7ceaeefa9800

We've upgraded to PLT v372, modified Halyard to use the precise GC,
and added debugging code to TSchemePtr (our scheme_immobile_box
wrapper) to make sure we're not leaking any uncollectable references
into the Scheme heap. None of this has fixed the problem.

Interesting facts about the memory leak:

 1) The leak is roughly proportional to the amount of code we're loading.
 2) If we load compiled code, we still appear to leak memory, but only
~1/5th as much as we do with the compiler disabled.

Brian Campbell has collected detailed notes on this problem, and I've
added instructions on checking out the "sandbox" branch of Halyard:

  http://iml.dartmouth.edu/halyard/wiki/index.php/Memory_leak

We're pretty much at a loss here. Is there anything else we should
try? Are there any other statistics we should take a look at?

Thank you for any advice you can provide!

Cheers,
Eric