OK, thanks. I grok the aliasing, I think (some sort of NULL pointer changes to be a pointer to a CV, which new pointer holds the same address as Base::f's pointer?) With the Devel::Peek output, is this what's going on?

(Looking at P5 source, the real magic behind Devel::Peek seems to be in Perl_do_sv_dump() in dump.c.)

• 2 calls to Devel::Peek::Dump
• Method call (dispatch)
• 1 call to Devel::Peek::Dump

Which translates to (first 2 calls):

SV = PVGV(0x816c6e8) at 0x814f6d8
  GP = 0x816c720
    CV = 0x814f714
SV = PVGV(0x816f938) at 0x814f810
  GP = 0x81709f8
    CV = 0x0             <-- &Child::f doesn't exist
    CVGEN = 0x0
[download]

(last):

SV = PVGV(0x816f938) at 0x814f810
  GP = 0x81709f8
    CV = 0x814f714       <-- &Child::f aliased to &Base::f
    CVGEN = 0x4d         <-- ...for method dispatch only
[download]

Within the pared-down Devel::Peek output:

SV = PVGV(0x816c6e8) at 0x814f6d8    # Reference (at 0x814f6d8) to typ
+eglob (at 0x816c6e8)?
  GP = 0x816c720                     # Address of typeglob? Has AV, HV
+, CV.
    CV = 0x814f714                   # Address of CV of f()

SV = PVGV(0x816f938) at 0x814f810    # Akin to above
  GP = 0x81709f8                     # ""
    CV = 0x0                         # Child::f()'s pointer to CV, equ
+iv place to Base::f()
    CVGEN = 0x0                      # "generated CV"? do you mean "th
+is CVGEN 'slot' is used for nothing else than method dispatch"?
[download]

Please ignore beyond here, massive tangent :)
No idea what 0x4d is, but within struct gp in gp.h, there is this:

... and I can find stuff like this:

gv.c
453:                GvCVGEN(topgv) = PL_sub_generation;
[download]

... and PL_sub_generation seems to be incremented all over the place in the source. Furthermore:

gv.c
457-        else if (topgv && GvREFCNT(topgv) == 1) {
458-            /* cache the fact that the method is not defined */
459:            GvCVGEN(topgv) = PL_sub_generation;

...

1433-       /* Adding a new name to a subroutine invalidates method ca
+che */
1434:       PL_sub_generation++;
[download]

GvCVGEN is a macro that gets at the CVGEN in the Devel::Peek output:

dump.c
1544:   Perl_dump_indent(aTHX_ level, file, "    CVGEN = 0x%"UVxf"\n",
+ (UV)GvCVGEN(sv));
[download]

... so line 3330 would relate to your "&Child::f doesn't exist" above:

sv.c
3330-       GvCVGEN(dstr) = 0; /* Switch off cacheness. */
[download]

The point was that calling the method added the method to the child's namespace so that @ISA needs not be scanned on later calls to that method.

Your questions go way beyond that, but I'll be happy to answer them anyway.

I think (some sort of NULL pointer changes to be a pointer to a CV, which new pointer holds the same address as Base::f's pointer?)

The CV field of the structure is the CODE slot of the glob. (See perldata)

I was showing that *Child::f{CODE} was assigned *Base::f{CODE}. That means Base::f and Child::f are the same function at that point.

do you mean "this CVGEN 'slot' is used for nothing else than method dispatch"?

*Child::f{CODE} is effectively undefined for everything that isn't a method call when CVGEN is true.

No idea what 0x4d is, but within struct gp in gp.h, there is [generational validity of cached gv_cv]

The cached entries need to be expired when there's a change to an @ISA, but keeping track of all the cached entries would require a fair amount of resource.

Instead of clearing all the cached entries (which would require keeping track of them), changing any @ISA simply increments a counter. If the cache's counter (CVGEN) is lower than the change counter, the cache is stale and thus ignored.

Or so goes my understanding.

I grasped the main point - but my curiosity got the better of me :)

Thanks for your detailed reply; it's highly appreciated. And your understanding (WRT cache expiration) makes perfect sense.

---

The zeroeth step in writing a module is to make sure that there isn't already a decent one in CPAN. (-- Pod::Simple::Subclassing)