[MLton] Progress on AMD64/FreeBSD

[Jesper Louis Andersen]

I just checked it on FreeBSD via a little C-program. It seems that FreeBSD
fails to map if the mapping is different from 0 and in an area which cannot
be mapped.

On 6/27/07, Jesper Louis Andersen <jesper.louis.andersen at gmail.com> wrote:
>
> That sounds like a fine approach. I wonder if the behaviour is different
> on 32bit FreeBSD. I'll check it for the sake of interest. I wont be able
> to dig too deep into it before the 1st I think but then it gets a round of
>
> work. I hope to get the runtime to run then.
>
>
>
> On 6/27/07, Matthew Fluet <fluet at tti-c.org> wrote:
> >
> > Matthew Fluet wrote:
> > > Jesper Louis Andersen wrote:
> > >> Matthew is right, it doesn't cycle. I came to the same conclusion
> > >> independently
> > >> of him. What nags me however is that since we are not doing MAP_FIXED
> > the
> > >> location is a hint to the kernel. In principle the kernel is free to
> > >> provide
> > >> us with
> > >> any memory area where it can fit the mapping.
> > >
> > > That appears to be how things work on linux.  There, we request an
> > mmap
> > > at the address 0xf800000000000000 and are returned an mmap at the
> > > address 0x00002aaaaaab2000.
> > >
> > > I thought that I read somewhere that mmap would return a higher
> > addresss
> > > than the one requested, but not a lower address.  Maybe that is what
> > is
> > > happening on FreeBSD.  It certainly isn't the case on Linux.
> > >
> > > But, presumably, there was some reason to put in the scan through
> > > memory.  As Jesper notes, one expects that without MAP_FIXED, we
> > should
> > > get back an address if there is enough space.
> >
> > I looked back through the SVN/CVS logs.  The mmap scan was added at
> > revision 834 (Feb. 5, 2002); the commit log indicates that it was a
> > PolySpace runtime modification, mostly for performance improvements.
> > A few days later, a comment was added to the code explaining that "This
> > toggles back and forth between high and low addresses to decrease the
> > chance of virtual memory fragmentation causing an mmap to fail.  This is
> > important for large (>1G) heaps."
> >
> > We have never used MAP_FIXED as an option to mmap.  Googling for mmap
> > man pages doesn't reveal any well-defined behavior of mmap (without
> > MAP_FIXED) in the presence of a hint address.
> >
> > In any case, I'll change the code to compute a scan stride equal to 1/32
> > of the address space.  That will give the same behavior on 32-bit
> > systems, and will presumably get us quickly to a successful mmap on
> > 64-bit systems that interpret the hint more strictly than linux.
> >
> >
> > _______________________________________________
> > MLton mailing list
> > MLton at mlton.org
> > http://mlton.org/mailman/listinfo/mlton
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mlton.org/pipermail/mlton/attachments/20070628/11614d2a/attachment.html