[MLton] Progress on AMD64/FreeBSD

[Matthew Fluet]

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.