Re: Fat references

On 2009-12-29, Jon Harrop <jon@ffconsultancy.com> wrote:
> I've been working on a project called HLVM in my spare time:
>
> http://forge.ocamlcore.org/projects/hlvm
>
> One goal was to have fast interop with C, so I didn't want to copy the
> traditional style of placing a header with GC metadata before every value
> in the heap because that would require C arrays to be copied just to add
> this header. I couldn't be bothered to allocate a separate header so,
> instead, I pulled the GC metadata into the reference. So my references are
> now "fat": a quadword of pointer to run-time type, array length or union


So now you have references that can't fit into a machine register.


> type tag, pointer to mark state and pointer to the actual data itself.


How do you fit three pointers and a tag into a ``quad word''?


You must be using ``quad word'' differently from the rest of the world,
where it is understood to be 64 bits, according to this convention:


16 bits: word
32 bits: double word
64 bits: quad word


In a 64 bit address space, just one single pointer is already a
quad-word.


> This actually works rather well except I sacrificed atomic read/write of
> references. Has it been done before?


Fat pointers have been implemented in some C compilers, to provide
run-time bounds checking on arrays and other objects.


From your description, it seems that what you describe resembles a
handle-based approach whereby some objects are split into two parts: a
fixed size record, which contains a pointer to the remaining storage, in
addition to other fields, like a type tag and whatnot. The fixed size
records are allocated in an array fashion from heaps, where garbage
collection takes place. However, the records are not regarded as
references, and are never passed by value. The reference values that
are manipulated by the program are actually pointers to these records,
not the records themselves. So in other words, you keep your fundamental
value/reference type of a size that fits into a register. If you need
atomic operations, you can do them nicely on that type. Variables,
including function arguments, and the slots of structure and vector
objects, are all just one pointer wide, so you can do a compare-swap (or
whatever) on any memory location that holds a value, whether it's a
local variable, array element, etc.

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