Re: Fat references

On Sun, 03 Jan 2010 09:36:40 -0800, Ray <bear@sonic.net> wrote:


>In the second iteration, I used fat pointers; Each pointer was the
>size of four native-architecture pointers where one was the pointer to
>the object on the heap, two were "forward" and "back" pointers that
>joined all pointers into a single doubly linked list, and one was a
>set of immediate binary flags (typetag, "soft" pointer, last pointer
>in this object, etc). Different regions of the list corresponded to
>different populations w/r/t Garbage Collection (traversed root,
>untraversed root, reached and traversed live data, reached but not
>traversed live data, not yet reached possibly-live data, and known
>garbage not yet finalized/deallocated). The garbage collector knew
>where the dividing points between these regions were, and would
>process pointers found at those points in the list, often moving them
>to one of the other boundary points. At "generation boundaries" when
>the "untraversed" section was empty, it would just shift the boundary
>points and start over. The GC code was very simple (<200 lines of C)
>and needed to know nothing about the internal structure of the
>user-defined types beyond a few bits set in the object allocators.
>
>I expected performance with fat pointers to be horrible, but it
>actually wasn't. It turned out to be faster than the first version,
>(on an AMD64 dual-core processor with 128K/2M cache), probably due to
>more inlined values (I was using a lot of doubles) and better locality
>of reference.


I suspect a good part of the overall improvement came from using the
treadmill GC. Treadmills are very fast and, so far, treadmill is the
only general GC model having performance predictable enough to enable
its use in some high speed HRT processing.


George

Return to the comp.compilers page.
Search the comp.compilers archives again.