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

On Wed, May 7, 2008 at 5:08 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>  It's a bug in v372 and earlier that causes MzScheme to use only 1/4 the
>  available address space under Windows.

Thank you for the fast response!

Is there a workaround or patch for this bug in 3.99.x? We're quite
happy to patch our PLT v372 tree.

>  > 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.

Would it be worthwhile to check for NULL and generate a fatal error
message when VirtualAlloc fails? That would at least make it possible
for users to distinguish between out-of-memory errors (which can be
safely ignored) and NULL-pointer segfaults (which should be reported
as bugs).

Of course, I'm not sure how to report an error from within the GC.

If you have any advice on how to report errors gracefully from within
the GC, we'd be happy to send you a patch.

>  Macro expansion creates large data structures to keep information about
>  the lexical contexts that come and go in the process of expansion.

I've observed an interesting pattern, which might be relevant:

  - When we load pre-compiled code, we end up using around 20MB of
core (for everything: code, data, etc.).
  - When we have to compile the code, we end up using around 80MB of core.

In either case, the memory can't be reclaimed until the namespace is
destroyed. Do the compiled modules keep any syntax information around?

Thank you so much for your debugging help and advice--you've helped us
make significant improvements to Halyard, and our in-house users have
been really happy all week.

Cheers,
Eric