This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: compressed pointer type implementation in gcc
On 7/20/08, Joe Buck <Joe.Buck@synopsys.com> wrote:
> On Sat, Jul 19, 2008 at 06:53:41PM -0400, Robert Dewar wrote:
> > Andi Kleen wrote:
> > 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.
>
> An alternative would be to design the program to use integers in
> the role of pointers, and allocate objects of a given type in pools
> that are contiguous in virtual address space. Then instead of a
> pointer to class Foo, you have an unsigned 32-bit integer, and the
> true address of the object is Foo_pool_base + offset. The offset
> is automatically scaled by the compiler, multiplied by sizeof(Foo).
I also thought along these lines, but this tends to complicate the solution.
Also note that while in theory the allocated address can come from
anywhere, in practice it does come from the low areas where sbrk
begins (empirically at least).
>
> The application could then scale beyond 32GB in many cases (especially
> if different kinds of objects are in different pools). The conversion
> from integers to pointers for dereferencing can be done in inline
> functions. Real pointers can be used as well where the cost is
> small. The application can then remain portable C or C++, and no
> compiler modification is necessary.
>
My thoughts exactly.
Moreover, I was thinking along the lines of keeping this as a
qualifier (am I using the right term?), i.e. writing:
void* my_ptr __aligned32__;
The compiler will compress it if a flag is given (just like the -fpack-struct).
The same would go for classes - if the base class has this trait, it
and all derived classes will have their virtual table pointer
compressed.
That way we achieve several goals:
1. Backwards binary compatibility.
2. vptrs can be achieved.
3. Controllability of where to compress (make sure runtime is not damaged).
On a different note, it is actually hard to decide which pointers can
be compressed at the compilation level (without user intervention)
seeing as some pointers are actually <8-byte aligned (i.e. char-s) and
forward declarations can make it impossible to discover.