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

At Wed, 7 May 2008 18:11:11 -0400, "Eric Kidd" wrote:
> 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.

Maybe all you have to do is, in newgc.c, change 

 #define LOG_APAGE_SIZE 14

to

 #define LOG_APAGE_SIZE 16


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

Yes, we should at least do that.

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

Are you measuring that with `current-memory-use', or some other way?
Forcing a GC a time or two before measuring?

When I start MrEd v4 without .zo files, after I get a prompt,
`(current-memory-use)' says 50 MB. After a GC, it's 19MB.

With .zo files, the initial memory use is 22.5 MB, and then it's 15MB
after a GC.

Source-location information is pruned when writing bytecode. Also, the
process of compiling probably triggers JIT compilation of code that
doesn't run otherwise. Those can account for a few megabytes, and I
think they explain the post-GC difference for MrEd, but those factors
can't explain 60 MB. Looking into this further may help us find another
problem.

Matthew