So every turf (aka 'process') has a special value. If this value is XORed with the high bits of a local pointer it turns it into a global pointer, and vice-versa.
Example: turf A has a local space register of 1010100000 (binary; lets keep the numbers small, but Mill addresses are really 60-bit). Note that the low five bits are 0. All local space masks will have some number of low bits 0.
A local address is 0000011000. Note that the high five bits happen to be zero. XORing in the local-space base would give the global address 1010111000.
Another local pointer might have the bit-pattern 0000100111. Note now that there is a bit set beyond the low zero bits in the mask; this time, the XOR will convert it into the global address 1010000111.
So as the local base mask has low bits all zero, all addresses within that span will be sequential in memory. But local space is disjoint in global space. This affects only the maximum continuous allocation size and not the total number of allocations.
When turf A forks, the child has to have local base mask that preserves the relative position of all allocations. But as the XOR mask will be different, the global addresses will not overlap for these 'local' allocations.
The vast majority of mmaps are actually shared (file buffers etc) and don't need this XORing. The CPU is transparently doing the XOR when needed and its nothing normal programs need to know about; only the kernel, when giving out new mmap regions, needs to know if it should hand out a global or local address.
So as the local base mask has low bits all zero, all addresses within that span will be sequential in memory. But local space is disjoint in global space. This affects only the maximum continuous allocation size and not the total number of allocations.
So I think what you're saying here is that that if turf 10101 has an allocated local address 0000100111, then turf 10100 can't have an allocated local address of 0000000111, because they correspond to the same global address - they'd clash.
Have you thought much about address space randomization? It's a reasonably effective security strategy, but it essentially requires enough unused bits in the address space. If you have a system with one big memory space, presumably your address space is now more precious, or do you still have enough bits for randomization (both in the local and the global spaces).
Being SAS and having PIC and data makes the way ASLR works different. But we're big fans of exploit mitigation techniques and I will be preparing a decent white paper or talk about it shortly.
Its natural for a normal OS to map their "processes" to Mill turfs. I make that jump in the explanation, but hold out hope that we can teach people to adopt a finer-grained approach where they sandbox and protect things within their program.
So every turf (aka 'process') has a special value. If this value is XORed with the high bits of a local pointer it turns it into a global pointer, and vice-versa.
Example: turf A has a local space register of 1010100000 (binary; lets keep the numbers small, but Mill addresses are really 60-bit). Note that the low five bits are 0. All local space masks will have some number of low bits 0.
A local address is 0000011000. Note that the high five bits happen to be zero. XORing in the local-space base would give the global address 1010111000.
Another local pointer might have the bit-pattern 0000100111. Note now that there is a bit set beyond the low zero bits in the mask; this time, the XOR will convert it into the global address 1010000111.
So as the local base mask has low bits all zero, all addresses within that span will be sequential in memory. But local space is disjoint in global space. This affects only the maximum continuous allocation size and not the total number of allocations.
When turf A forks, the child has to have local base mask that preserves the relative position of all allocations. But as the XOR mask will be different, the global addresses will not overlap for these 'local' allocations.
The vast majority of mmaps are actually shared (file buffers etc) and don't need this XORing. The CPU is transparently doing the XOR when needed and its nothing normal programs need to know about; only the kernel, when giving out new mmap regions, needs to know if it should hand out a global or local address.