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.
Matthew Fluet wrote:
> Jesper Louis Andersen wrote:
>> Matthew is right, it doesn't cycle. I came to the same conclusion
>> 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
>> 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