On Wed, Jul 29, 2009 at 1:14 PM, Andrew Dougherty<[email protected]> 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. 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. 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. Again, we can use casts inside the GC to reuse fields for forming the free list if necessary. --Andrew Whitworth _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
