Re: Fat references

Jon Harrop <jon@ffconsultancy.com> writes:


> 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
> type tag, pointer to mark state and pointer to the actual data itself.
>
> This actually works rather well except I sacrificed atomic read/write of
> references. Has it been done before?


GNAT (the gcc Ada compiler) uses fat pointers by default to represent
pointers to unconstrained arrays. (Unconstrained means different
objects of a given array type can have different lengths.) The fat
pointer consists of the address of the bounds and the address of the
data.


One advantage is that it can use zero-origin indexing. That is, if
the bounds of the array are 10..20, the data address points to the
0'th array component, even though that component doesn't exist. So
indexing doesn't need to subtract off the lower bound.


The purpose of these fat pointers has nothing to do with GC, though.
GNAT does not currently support GC, except for the versions targeting
.NET and the JVM.


The user can also request thin pointers, which are the address of the
data, with the bounds stored just before the data. The zero-origin
trick won't work in this case.


I don't fully understand the problem you're trying to solve, nor how
fat pointers are the solution. Are you saying all pointers are fat (4
words per pointer!?)? Or just pointers to arrays? Under what
circumstances are you worried about an extra copy? If the array is
allocated on the C side, you have to concoct the meta data somehow...


Why not just say that arrays allocated on the C side are not
subject to GC?


By the way, if you're interested in GC, you should join the
GC list, which our esteemed moderator set up some years ago.


- Bob

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