Programming, Software and Code

Contexts into PMCs: The plan

Turning Parrot_Context structures into PMCs is not going to be a trivial process. There are a number of reasons for this:
  1. Contexts are very complicated structures
  2. Contexts are very central to the operation of Parrot, so any conversion will affect the majority of the codebase
  3. The VTABLE interface is designed for data items that serve a singular purpose, while Contexts serve several purposes in Parrot. There isn't going to be a good fit between what needs to be done with Contexts to the VTABLE interface.
Since VTABLEs are relatively limited, any Context PMC is likely to require a number of direct accesses to the various internal data fields using the {GET|SET}_ATTR_* macros. If we tried to use a STRING-based property lookup to access internal members, it would be a major performance bottleneck for Parrot. A STRING-based property lookup could also be available to allow introspection from the PIR level, but that's separate issue entirely (although a nice perk to think about!)

Here are some ideas for what the VTABLE interface might be able to be used for:
So that's a brief overview about what the VTABLE interface to the Context PMC will look like. Obviously we will also implement basics, like destroy, init_pmc, visit, mark, freeze, thaw, etc. These will all do the kinds of operations we expect of any PMC.

Here are some of the initial steps that I think we can take to replace struct Parrot_Context with Context PMCs. I think that if we can follow these steps we should be able to keep Parrot stable throughout the conversion process without allowing anything to be broken for too long:
  1. Encapsulate all the existing fields into a new PMC with no vtables and no methods
  2. Modify the PMC to remove fields used for ref-counting, and replace pointers to other contexts with pointers to Context PMCs.
  3. Modify the Context allocation/initialization routines in src/gc/register.c to allocate a new Context PMC instead
  4. Modify the CONTEXT(interp) macro to be ((Parrot_Context_attributes)PMC_data((interp)->ctx)) instead of ((interp)->ctx.state). At this point, the switch over to the new Context PMC should be complete, and Parrot should be using the PMC directly (although with very little respect for encapsulation) for all it's context-related needs.
  5. Implement various VTABLE methods to handle some common operations, and replace direct ATTR accesses with VTABLE calls instead.
  6. Optimize like a crazed elephant
  7. Profit!

What's really interesting in all this, which is something I've alluded to earlier, is that we open the possibility for Contexts to be manipulated in PIR code and introspected from there as well, things that are not currently possible. What kinds of cool control structures and situations will people develop once we have this?

This entry was originally posted on Blogger and was automatically converted. There may be some broken links and other errors due to the conversion. Please let me know about any serious problems.