develooper Front page | perl.perl5.porters | Postings from April 2007

mro status, etc

Thread Next
From:
Brandon Black
Date:
April 25, 2007 16:37
Subject:
mro status, etc
Message ID:
84621a60704251637v1f4a3f84y19b39461166e3631@mail.gmail.com
I thought I'd start up a new thread here since the other one had
gotten huge.  Just wanted to post a status summary/update of what's
going on the the mro.c stuff, and other related things that I'm
working on:

Outstanding known issues / little patches:

  1) The overload.pm "ARRAY" thing: I think this is resolved now with
the latest official changes to overload.pm
  2) Autodoc stuff: I posted a patch in a different thread, it may
have gotten lost or it may need further fixing, it's attached here as
"mro_docs.patch"
  3) I just found a new bug in mro.c.  Attached is a patch
"mro_bugfix.patch" (mro.c code was assuming that child classes never
went away, which they can do sometimes).

Finishing off the efficiency stuff:

I'd like to remove the remaining "PL_sub_generation++" (sometimes it's
++PL... if you're grepping) from all other files than mro.c if I can,
replacing them with calls to mro_method_changed_in() if
possible/necessary.  There are three instances left:

1) The one in gv.c:Perl_gp_free().  This is the last big one, and I
have a branch locally where I'm working on this issue by solving all
of the cases that call gp_free one by one.  This should come together
soon.  Once I have this one nailed down I'll be able to feel more
confident about removing the ugly commented-out one in gp_ref as well.

2) The one in op.c:newATTRSUB(), which only occurs under the debugger.
 I don't really know what's going on there, but it's probably related
to the PL_sub_generation checks in pp_ctl.c:pp_entereval, which seems
to want to change something about what happens after an eval if
subroutines were defined during the eval, but again only under the
debugger.  I'm not too worried as this all only matters under the
debugger, but it would be nice to resolve it.

3) The one in pp_hot.c:pp_sassign(), which appears to only happen on
assigning a CV to a GV who's name is "isa".  My best guess to date was
that this has something to do with strange inheritance/method-cache
semantics for UNIVERSAL::isa, or was part of some never-finished plan
to let people change inheritance by overriding the ->isa method.  As
the comment there currently says, I don't really know.

@ISA Modification Efficiency:

Currently, the setisa magic that keeps all of this mro stuff working
sanely (mro_isa_changed_in, called from mg.c:Perl_magic_setisa()) is
called more often than necessary.  For instance, when one does
"@Foo::ISA = qw/ A B C D/", it gets called 5 times in a row (once to
clear the array, and then once for each element pushed on), because
that's just how the array magic works.  It would be a lot more
efficient to only invoke the magic once per real perl statement
affecting an @ISA.  Perhaps some special cases in aassign or something
like that could delay the setisa magic until the end of the
assignment.  I don't know, I haven't gotten around to working on this
yet, but I plan to.

Introspection Interfaces:

Lastly, I'd like to provide some good interfaces for future CPAN
modules to be able to readily detect when the methods or @ISA of a
package they care about has changed.  Some of the mro::* functions
were originally planned to give that sort of introspection, but as
things stand now they don't, they really just provide introspection on
method caching issues, which is really different and far less useful.

I had posted an experimental patch for modules to register callbacks
for this in another thread.  Another way to do it would be to add two
more integers to the mro_meta struct to track the "generation" number
of the changes to methods/isa in this stash, which would be true
equivalents of the old PL_sub_generation (unlike the current (poorly
named?) mro_meta->sub_generation, which the method cache code uses,
but doesn't necessarily reflect local changes).  The integers would be
simpler and faster, but modules using them will need to check them
explicitly, whereas the callback mechanisms let them get notified
immediately.

In either case, I'll probably yank the mro::* method that currently
reports mro_meta->sub_generation in place of whatever better solution
comes about.

If anyone has any useful information/insight/ideas/code/etc along any
of the above lines, please feel free to pipe up :)

-- Brandon

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About