[Parrot] #549: Kill UnionVal

[Andy Dougherty]

On Wed, 29 Jul 2009, Andrew Whitworth wrote:

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

I'm afraid I don't understand.  *Which* existing PMC storage space would 
be re-used?  Here's the current PMC structure:

    struct PMC {
	UnionVal        cache;
	Parrot_UInt     flags;
	VTABLE         *vtable;
	DPOINTER       *data;
	struct PMC_EXT *pmc_ext;
    }

If you remove the UnionVal, you have
    struct PMC {
	Parrot_UInt     flags;
	VTABLE         *vtable;
	DPOINTER       *data;
	struct PMC_EXT *pmc_ext;
    }

What specific structure definition would be "overlayed" on that?

Also when you use such casts, you have to be particularly careful about
alignment constraints.  One good, efficient, self-documenting, portable
way to do that is to use unions.

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

Fine.  That's a good abstract goal.  Is there anything more specific?

-- 
    Andy Dougherty		doughera at lafayette.edu