Even more interesting...

ANOQ of the Sun anoq@hardcoreprocessing.com
Mon, 05 Jun 2000 23:32:09 +0200



"Stephen Weeks" wrote:
> 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.

Thanks a lot!

> So, there are several possible workarounds.
> 
> * Find a windows equivalent of mmap/munmap and use those, not malloc
>   and free.

I think the closest is VirtualFree and VirtualAlloc that I use :(

> * Run with a fixed heap, and patch maybeShrinkStack.
> * Run with a fixed heap and a fixed stack.

I don't much like the sound of this - especially for a
converter which should be able to convert arbitrarily
large files or maybe run on systems with little memory.

But I have another idea:

Whenever I get the 487 error code - I could just ignore it
and say "hey - we couldn't free that memory - too bad".
Occationally I guess the original address will be freed
anyway - isn't that right? However I don't know if the GC
would later request that the address which was supposed to
be freed should be allocated again - in which case we're
allocating an already allocated address.

But it seems to me that smmap only requests for a given
length - not an address.


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