[Parrot] #549: Kill UnionVal
doughera at lafayette.edu
Wed Jul 29 19:58:40 UTC 2009
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
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
More information about the parrot-dev