[Parrot] #549: Kill UnionVal

Andrew Whitworth wknight8111 at gmail.com
Thu Jul 30 00:06:18 UTC 2009


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

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.

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

Yes, unions in general are a good tool for this purpose. However, the
UnionVal itself is not a good implementation of that. UnionVal is,
simply, not the right solution to any problem that Parrot faces.

--Andrew Whitworth


More information about the parrot-dev mailing list