[Parrot] #549: Kill UnionVal

[Andrew Whitworth]

On Wed, Jul 29, 2009 at 11:17 PM, Andy Dougherty<doughera at lafayette.edu> wrote:
> On Wed, 29 Jul 2009, Andrew Whitworth wrote:
>
>> On Wed, Jul 29, 2009 at 5:21 PM, Andy Dougherty<doughera at lafayette.edu> wrote:
>> > On Wed, 29 Jul 2009, Andrew Whitworth wrote:
>> > I'm afraid I don't understand.  *Which* existing PMC storage space would
>> > be re-used?  Here's the current PMC structure:
>
>> The only thing that the GC needs right now is enough storage for a
>> single pointer, which can be used to arrange PObjs into a linked list
>> of free items. See, for example, the structure GC_MS_PObj_Wrapper
>> which is used in the MS GC right now for this exact purpose.
>
> Ok, so that's effectively using "bufstart".  There are also a lot of
> references in src/gc/api.c (as well as lots of other files) to "buflen".
> I don't know if they are necessary, but it's not obvious how to get rid of
> them.  And if both bufstart and buflen are needed, then we're back
> where we started -- no space savings.

It's only effectively reusing the space for "bufstart" because
bufstart is still part of the structure. Once we remove bufstart from
the PMC, the pointer will be overlayed on a different field in the
structure and there will be memory savings. The buflen thing similarly
could be overlayed (or maybe be removed entirely) for additional
savings. There is no fundamental reason why PMCs need to be as large
as they are now, considering that the things using that space (inside
and outside the GC) are orthogonal to one another and non-overlapping.

> Please note I am not arguing either for or against UnionVal.  I was
> simply seeking a direct answer to the simple question
>
>   "What, exactly, are those structures supposed to look like after this?"

In the long term, I suspect PMCs will look like this:

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

Or maybe this, if PMC_EXT is common enough that we can prevent it from
being a separate structure:

struct PMC {
    Parrot_UInt flags;
    VTABLE *vtable;
    DPOINTER *data;
    PMC *metadata;
    struct _Sync *synchronize;
};

STRING will look like this:

struct parrot_string_t {
    Parrot_UInt flags;
    char       *strstart;
    void *_bufstart;
    UINTVAL _buflen;
    UINTVAL     bufused;
    UINTVAL     strlen;
    UINTVAL     hashval;
    const struct _encoding *encoding;
    const struct _charset  *charset;
};

And I'm sure there is some extra bloat here in this structure that we can avoid.

--Andrew Whitworth