[MLton] Progress on AMD64/FreeBSD
Jesper Louis Andersen
jesper.louis.andersen at gmail.com
Wed Jun 27 14:08:56 PDT 2007
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/20070627/99f4cd7e/attachment.htm
More information about the MLton
mailing list