[Parrot] #549: Kill UnionVal

[Andy Dougherty]

On Wed, 29 Jul 2009, Andrew Whitworth wrote:

> On Wed, Jul 29, 2009 at 1:14 PM, Andrew Dougherty<doughera at lafayette.edu> wrote:
> > Could someone remind me *why* we should "Kill UnionVal" ?  I've reviewed
> > the #parrot link referenced in TT #549, pdd17, and the old RT #48014, but
> > I still don't understand what "problem" this ticket is trying to solve.
> 
> Several problems, in fact, although many of them are specific to PMCs
> and not to all PObjs.
> 
> 1) Most PObjs, PMCs included, only use part of the UnionVal structure,
> making the rest of it a waste of memory space.
> 
> 2) PMC data is not stored in the UnionVal because that creates a huge
> problem with subclassing PMCs, including PMCs written in C and PIR.
> All data from PMCs now is stored in attribute structures and UnionVals
> are completely unused and is a complete waste of space.
> 
> At the very least we would like to apply this patch or something like
> it to get UnionVals out of the PMC structure completely to save space.

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.

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

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

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

Before starting, it might be useful to have a sense of which way to go.

-- 
    Andy Dougherty		doughera at lafayette.edu