Re: Fat references

Jon Harrop <>
Fri, 01 Jan 2010 06:10:02 +0000

          From comp.compilers

Related articles
[3 earlier articles]
Re: Fat references (BGB / cr88192) (2009-12-30)
Re: Fat references (glen herrmannsfeldt) (2009-12-30)
Re: Fat references (Jon Harrop) (2009-12-30)
Re: Fat references (Kaz Kylheku) (2009-12-30)
Re: Fat references (Jon Harrop) (2009-12-30)
Re: Fat references (glen herrmannsfeldt) (2009-12-31)
Re: Fat references (Jon Harrop) (2010-01-01)
Re: Fat references (BGB / cr88192) (2010-01-01)
Re: Fat references (BGB / cr88192) (2010-01-01)
Re: Fat references (2010-01-02)
Re: Fat references (glen herrmannsfeldt) (2010-01-02)
Re: Fat references (Robert A Duff) (2010-01-02)
Re: Fat references (Jon Harrop) (2010-01-03)
[19 later articles]
| List of all articles for this month |

From: Jon Harrop <>
Newsgroups: comp.compilers
Date: Fri, 01 Jan 2010 06:10:02 +0000
Organization: Flying Frog Consultancy Ltd.
References: 09-12-045 09-12-055
Keywords: storage, GC
Posted-Date: 01 Jan 2010 11:43:56 EST

Kaz Kylheku wrote:
> On 2009-12-29, Jon Harrop <> wrote:
>> I've been working on a project called HLVM in my spare time:
>> 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,

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


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

Post a followup to this message

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