Changes between Initial Version and Version 1 of ClassVtableOverrides

11/20/09 22:26:50 (12 years ago)

a plan and a plea for volunteers


  • ClassVtableOverrides

    v1 v1  
     1PIR classes can override VTABLE entries with PIR functions, but detecting this is costly: it requires every Object VTABLE entry to perform a check for a VTABLE override on every VTABLE invocation. 
     3Most Objects never override any VTABLE entries. 
     5We can detect whether a class has overridden a VTABLE entry; the add_vtable_override() method in the Class PMC is a good place to perform a bit of magic. 
     7For this trick, we need: 
     9* a comprehensive set of VTABLE entries which *only* dispatch to the given PMC Object's Class's PIR VTABLE override 
     10* a way of mapping the name of a VTABLE entry (passed to add_vtable_override()) to the appropriate slot in the fake VTABLE 
     11* a way of swapping the standard Object VTABLE for a custom VTABLE for all Object PMCs created by the instantiate() of a Class with overridden VTABLE entries 
     12* (likely) a way of identifying whether any *parent* Class in a Class's MRO has overridden VTABLE entries 
     14Thus every time something adds a new VTABLE entry to a Class, add_vtable_override() copies the current object VTABLE, swaps in the appropriate "dispatch to the PIR entry instead" VTABLE entry, and uses that new VTABLE for all Objects instantiated from that Class. 
     16We can then remove all "check for override" code from every other part of the system. 
     18Volunteers welcome for any or all parts of this.