[Parrot] #549: Kill UnionVal

[Andrew Whitworth]

On Wed, Jul 29, 2009 at 3:58 PM, Andy Dougherty<doughera at lafayette.edu> wrote:
> Except that this patch doesn't save any space at all on most
> architectures.  I understand and support the idea of saving space.  It's
> just not relevant for this patch.

That may be, I haven't examined this patch yet so I don't know what it
does (or even if it does it correctly)

>> The GC does use the UnionVal now (or, at least, the space where the
>> UnionVal is) to hold pointers to keep the PMCs on the free list. With
>> some work we could avoid that and hold free list pointers in other
>> fields.
>
> But why wouldn't those fields take up just as much space as they do now?
> Again, I'm not seeing the space savings.

It's not adding new pointer fields to the PMC for use internally by
the GC. It's creating a structure definition and overlaying that onto
a PMC by using a cast. In this case we'd be reusing the exising PMC
storage space for holding new pointers that would only be used
internally by the GC.

>> Other PObj-like structures, (List_Chunks, STRINGs, etc) can be
>> modified to not use UnionVal because it's not necessary and specific
>> pointers can be added to those structures for their particular needs.
>
> That sounds like a good idea, but there is a more basic question:
>
> What should those structures look like, ideally?  Would we end up
> effectively just adding in those fields again?

In some cases maybe, but we'd be adding the fields back in a way that
was much cleaner and more direct. No matter how you look at it, the
UnionVal serves no benefit in a STRING whatsoever, besides making it
compatible at the level of storage offsets for handling by the GC
(which again, we can get past if we overlay new structures on them
using casts).

For List_Chunks and STRINGs we should remove UnionVal because it is
bad design and serves no purpose besides unnecessary code obfuscation.

> I'll note that 3 months ago, on TT #549, I posted the same question:
>
>   A good starting question might be: "What, exactly, are those structures
>   supposed to look like after this?"

Exactly the same, but cleaner. Maybe a little smaller if we are smart about it.

--Andrew Whitworth