Re: Fat references

Kaz Kylheku wrote:
> 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.


If you don't have 128- or 256-bit registers on your 32- or 64-bit machine,
respectively.


>> 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''?


I grew up with 32-bit words (ARM) and meant 4*sizeof(void *).


> You must be using ``quad word'' differently from the rest of the world,
> where it is understood to be 64 bits...


No, there is no consistent meaning.


>> 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.


Thanks.


> 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.


I see. That is not what I'm doing but, besides atomicity, what is the
motivation for trying to squeeze a reference into a pointer?


--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u

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