Go's march to low-latency GC

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 12 July 2016 at 13:28:33 UTC, jmh530 wrote:
> On Monday, 11 July 2016 at 17:23:49 UTC, Ola Fosheim Grøstad 
> wrote:
>>
>> You can, but OSes usually give you randomized memory layout as 
>> a security measure.
>
> What if the memory allocation scheme were something like: 
> randomly pick memory locations below some threshold from the 
> 32bit segment and then above the threshold pick from elsewhere?

One possible technique is to use contiguous "unmapped" memory 
areas that cover your worst case number of elements with a 
specific base and just use indexes instead of absolute 
addressing. That way you often can just use 16 bits typed 
addressing (assuming max 65535 objects of a given type + a null 
index).

The base address may then be injected (during linking or by using 
self-modifying code if the OS allows it) into the code segments. 
Or you could use TLS + indexing, or whatever the OS supports.

Using global 64 bit pointers is just for generality and to keep 
language-implementation simple.  It is not strictly hardware 
related if you have a MMU, nor directly related to machine 
language as such. For a statically typed language you could 
probably get away with 16 or 32 bits for typed pointers most of 
the time if the OS and language doesn't make it difficult (like 
the conservative D GC scan).