[plt-scheme] 372: 3m does not check for VirtualAlloc failure

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Wed May 7 17:08:23 EDT 2008

At Wed, 7 May 2008 13:46:05 -0400, "Eric Kidd" wrote:
> I'm not sure why VirtualAlloc is failing at only 400MB (the system has
> barely even touched swap yet). 

It's a bug in v372 and earlier that causes MzScheme to use only 1/4 the
available address space under Windows.

> But the GC should probably be prepared
> for VirtualAlloc to return NULL, and do something sensible.

This is a deep weakness of the current GC implementation; it needs to
allocate some memory to perform a collection.

I agree with your conclusion, but I don't know how to fix it, yet.

> [1] I'm not sure why the compiler allocates and holds onto so much
> memory, but it all goes away when the namespace gets GC'd. Is the
> compiler storing some kind of compilation-related data somewhere in
> the module's data structures? I need to look into this...

We have no clear answer on this one.

Macro expansion creates large data structures to keep information about
the lexical contexts that come and go in the process of expansion. We
continue to find ways to compress and prune those data structures, but
they're still too big. Errortrace probably aggravates the problem by
expanding and re-expanding.

And then there are the possibilities for leaks and temporary leaks,
where data hangs around a little longer than it should. We've made some
progress lately on this front, too, but it's difficult to say whether
it would improve memory use for your example.


Posted on the users mailing list.