Matthew is right, it doesn't cycle. I came to the same conclusion independently<br>of him. What nags me however is that since we are not doing MAP_FIXED the<br>location is a hint to the kernel. In principle the kernel is free to provide us with
<br>any memory area where it can fit the mapping.<br><br>I hope to get some time for investigating the coming days. There are a couple of<br>rather loose ends to verify.<br><br><div><span class="gmail_quote">On 6/24/07, <b class="gmail_sendername">
skaller</b> <<a href="mailto:skaller@users.sourceforge.net">skaller@users.sourceforge.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, 2007-06-23 at 19:57 -0500, Matthew Fluet wrote:<br>> Jesper Louis Andersen wrote:<br>> > ok, new hypothesis:<br>> ><br>> > printing the right size of the pointer gives<br>> ><br>> > Couldn't map f7ff9954b0000000, 94208
<br>> ><br>> > etc. So I think this area is non-mappable for som reason. More<br>> > investigation<br>> > needed.<br>><br>> It could be that FreeBSD just doesn't release the very high addresses
<br>> for mmap'ing. And it is just taking forever to work our way down to the<br>> available addresses.<br>><br>> We'll want to increase the scan stride for a 64-bit system.<br><br>I think on Linux, the whole upper half of the address space is reserved
<br>for the kernel. [Still .. Mlton does work 64 bit on Ubuntu]<br>There are descriptions of the memory models somewhere.<br>To me this number: f7ff9954b0000000 looks like a stack address.<br>I don't really have any expertise though.
<br><br>--<br>John Skaller <skaller at users dot sf dot net><br>Felix, successor to C++: <a href="http://felix.sf.net">http://felix.sf.net</a><br></blockquote></div><br>