Re: [perl #48014] [DEPRECATED] PMC union struct

[email protected] (Christoph Otto) Fri, 16 Jan 2009 15:44:18 -0800
Newsgroups perl.perl6.internals
Message-ID <[email protected]>
Christoph Otto via RT wrote:
> I'm running into a snag trying to implement this.  It turns out that
> many lines which use the PMC_x_val macros use them on different types of
> PMCs, especially parents and children (e.g. FixedPMCArray and
> ResizablePMCArray).  There are also some instances where the PMCs with a
> related purpose but no inheritance (e.g. RetContinuation and
> ExceptionHandler) have the unionval used in the same way on a line of code.
> 
> What's the right way to fix these cases to use the GETATTR/SETATTR macros?
> 
> I have a file that lists these, which I'll be sticking on the wiki later
> tonight.

Here's the more detailed version:

Thanks to Infinoid++, I was able to follow particle's recommendation earlier 
in the thread and modify the PMC_x_val macros to record some information at 
runtime.  This will make the cage task *much* more approachable and 
parallelizable, but it also exposes places where code makes promiscuous 
assumptions about PMC internals.

The referenced files were generated by modifying include/parrot/pobj.h [1], 
then building and testing Parrot and any currently maintained HLLs that use 
custom PMCs.  The results are on trac, sorted by file [2] and by PMC [3].  I 
did this to help clarify how the UnionVal macros would need to be converted to 
GETATTR/SETATTR macros, since the latter are PMC-specific.  The files are 
generated from r34501 and can be regenerated as needed.

The problem with using ATTRs in their current state is that, depending on 
control flow, a given instance of a PMC_x_val may be called with several 
different PMC types (see src/hash.c:1045 in [2] for an extreme case).  This is 
fairly common and makes ATTRs unusable for any PMCs whose UnionVals are 
twiddled by common code.

One solution to this would be to make ATTRs follow the inheritance chain so 
the following code works:

PMC *foo = new_pmc(INTERP, enum_class_Foo); /*Foo has no ATTRs, extends Bar*/
INTVAL baz;                                 /*Bar has a "baz" ATTR*/
GETATTR_Bar_baz(INTERP, foo, baz);


I'm not attached to any particular solution, but it's clear that the migration 
away from the PMC UnionVal can't happen without some kind of significant change.


[1] http://xrl.us/becsw4 (diff)
[2] http://xrl.us/becswu (csv, sorted by source code file)
[3] http://xrl.us/becsww (csv, sorted by PMC type)