Even more interesting...

[ANOQ of the Sun]

"Stephen Weeks" wrote:
> 
> > But I have another idea:
> ...
> > Whenever I get the 487 error code - I could just ignore it
> 
> I don't think this is such a good idea either.  Here are two more
> possibilities.
> 
> * Never shrink the stack or heap.
>   It should be easy to modify gc.c to do this.  The weird smunmap
>   calls only happen when shrinking memory regions.

I have thought of this too - I think it is a good solution.
In practice it just means that the app. will always use as
much as it's peak amount of memory - except of course it may
be more, since it is really the sum of the peak of the
stack and the heap :)

I'll implement this with a conditional #define
for the MLton runtime library. Then I will set this
flag automatically for the Win32 platform - until
a better solution for Win32 might be implemented.

> * Fix gc.c to not use weird smunmap calls.
>   While not as easy as the above, this shouldn't be too bad.
>   Whenver the GC uses the smunmap call to shrink a chunk of memory
>   (either a stack or heap), you could instead allocate a new chunk of
>   memory of the smaller size, copy over, and free the old memory.  Or,
>   you could try using realloc, as Henry mentioned.

Wouldn't this give problems with other areas of memory pointing
to these areas? So that one would have to forward all pointers?
I don't think I would dare make such a modification to
the GC when I didn't write it myself :)


Cheers
-- 
http://www.HardcoreProcessing.com