Even more interesting...

[Stephen Weeks]

> What's also interesting is, that
> when running on Linux - the stack also
> shrinks to size 262144, which is followed
> by an smunmap with an address which does
> not seem to be smmap'ed earlier (but this
> time I didn't go through all adresses, but
> I only saw the same pattern as before).
> Again I could find an smmap'ed address with
> an address of 0x40000 lower than the smunmap
> after the stack shrink.
> 
> So it seems to me there's a bug in the stack-shrinking
> code. Can you figure out what might be wrong in the code?
> I can compile my program for you on Linux with
> whatever debug messages you like - if that is any
> help.

Henry figured out the problem.  This is not a bug in the GC code.
Here is Henry's mail.

> I  suspect  that  it is NOT a bug in the code, but a failure in mapping it to
> the evil Windows world.  Note, it is completely legal  to  mmap  a  chunk  of
> memory  from A to B and to then unmap from C to B where C is strictly greater
> than A (but less than B).  Thus, converting mmap to malloc and munmap to free
> is NOT correct.
> 
> The call to smunmap in maybeShrinkStack (in gc.c) should be changed from
>     smunmap(s->stackBottom + keep, s->stackSize - keep)
> to a realloc call, like
>     realloc(s->stackBottom, keep)
> but  if the result isn't equal to s->stakBottom (which IS leagal for realloc)
> then things have moved and you are dead.  Also there are other smunmap  calls
> which seem to be doing the same thing.  I don't see an easy work around.

As Henry correctly points out, there are many places in the runtime
that use this ability of smunmap.  If you run with fixed-heap, then
the only one that will be used is the one on line 469 of gc.c.  So,
there are several possible workarounds.

* Find a windows equivalent of mmap/munmap and use those, not malloc
  and free.
* Run with a fixed heap, and patch maybeShrinkStack.
* Run with a fixed heap and a fixed stack.