[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