Re: Fat references

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message


> Jon Harrop <jon@ffconsultancy.com> writes:
>> Memory consumption is only increased for duplicated references
>> (i.e. when two or more references in the heap point to the same value)
>> but I believe that is comparatively rare.
>
> That's a good point.
>
> But don't forget to count 'null' pointers. For example, consider
> a balanced binary tree of depth 3. You've got 7 nodes and
> 7 non-null pointers to them (one from outside the tree).
> But you've also got 8 null pointers stored in the leaf
> nodes. As I understand it, those 8 null pointers are
> going to be 4 words each, in HLVM.
>
> You can think of 'null' as being a pointer to a single
> dummy object -- and there are typically lots of duplicates!
>
<snip>
>
> Anyway, if you've got good measurements, they trump my
> speculation.


yep.


I at first had more than a few doubts, but had later discovered that
the VM was actually a very different technology than I had originally
thought, namely: it is statically typed, ...


so, yeah, 128 or 256 bit references performing well with static typing
is much easier to understand...


the main difference is in how things work:
in static typing, most things are not references;
in dynamic typing, almost everything is references.


I hadn't originally considered this, as I tend to use a large amount of
"mixed typing" instead.




>>...Indeed, a lot of literature on reference counting says that this
>> is so and, hence, 1-bit reference counts that saturate can still be
>> useful.
>
> Yes, I've read that. There are lots of GC schemes that take
> advantage of that.
>


yep.


my guess:
0 not/encodable
1 0
2+ 1


I have typically used more bits 2-4, and allow 0 to be encodable (misc
reasons, mostly so that an operation can do a "safe decrement" and
re-increment without freeing the object, because it makes more sense
to me to allocate an object with count=0 so that putting it into a
variable will make the count=1, ...).




> - Bob

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