compressed pointer type implementation in gcc

[Robert Dewar]

Andi Kleen wrote:
> "Yair Lifshitz" <luna.starlight@gmail.com> writes:
>> Basically, as long as the application is in the 32G range (2^32*2^3),
> 
> Seems like a strange assumption. If the application can use 32GB
> what stops it from using 40GB or 64GB? Systems with that much 
> memory are readily available these days.

Well the idea would be specifically for applications that can live
in 32 GB. If you compile in this mode, obviously you can't play
this trick, and you have to be sure that malloc cooperates in
limiting memory to 32G. On a system with allocate on use, you
could perhaps allocate 32GB in a chunk, and then use an allocator
within this 32GB which deals with compressed pointers.
> 
>> Would be nice to get your opinions on it.

> But on the C compiler level the problem is that you'll have an
> completely own ABI and won't be able to use any standard libraries
> unless you recompile them. And no system calls without a translation
> layer or some way to tag all system interfaces to the the standard
> ABI.  Java avoids that by having clearly defined interfaces to the
> outside world, but that's not the case in C.  Or you annotiate all
> structures where this translation should happen.

Not trivial, but seems addressable, either by recompiling the library
specially for this mode, or providing an interface layer, or by
providing some kind of mechhanism for indicating that certain
routines are compiled in normal mode.