develooper Front page | perl.perl5.porters | Postings from July 2010

RFD - my use-case of peepp

Thread Next
Jim Cromie
July 27, 2010 12:28
RFD - my use-case of peepp
Message ID:
Runops::Global tests the theory that we could drop
*	op_ppaddr	Pointer to current ppcode's function.
from OP, and just use PL_ppaddr[op->op_type]

For customized op-ppaddrs, we could steal one of op->spare bits,
(say:  op->ppaddr_custom_flag)
and if its set, lookup into some kind of custom storage;

1- a hash, indexed by &op
This is good for call-site specific wrappers, breakpoint or monitor
No Good for global pp-function replacement;
the hash could get very big, and expensive to use.

2- a sparse array, indexed by op->op_type.
This is suitable when the program wants 2 kinds of (forex) nextstate ops,
or perhaps 2 per Package

3 - obviously, a univerally applicable pp-customization could just
replace the value in PL_ppaddr[], and wouldnt set the flag

should I rename it ?
I was thinking Runops::OpAddr, but held off cuz of the minor rename hassle.

should I release it ?
It has no real value as an add-on, except as a demonstration,
since the OP mem isnt reduced without its inclusion in core.

So, how do I run 'make test' against it?

Ive installed bleadperl, and built and installed Runops::Global against it,
so this works:

perl-git]$ ./perl -Ilib -I ../cpan/Runops-Global/blib/lib/ -I
../cpan/Runops-Global/blib/arch -MRunops::Global=stats t/base/cond.t
ok 1
ok 2
ok 3
ok 4
zeroed 74 OPs
kept   0 custom OPs
called peep 0 times on null OPs
called peep 9 times on real OPs
of which 8 times had revisits

make test fails, cuz miniperl doesnt do -M

export PERL5OPT=....
cd t; ./perl harness

doesnt feed envar into forked jobs, does work upon harness itself,
but thats not the acid test Im after.

I tried a quick hack to harness, but it did exactly nothing.

index 88a7bfa..54a8122 100644
--- a/t/harness
+++ b/t/harness
@@ -212,6 +212,8 @@ my $h = TAP::Harness->new({
     rules       => $rules,
     color       => $color,
     jobs        => $jobs,
+    lib                => "../../cpan/Runops-Global/blib/lib
+    switches   => '-MRunops::Global=stats -DUv',
     verbosity   => $Verbose,
     exec        => sub {
        my ($harness, $test) = @_;

Im wondering if there is a "best way / recommended method"
to run core tests against non-core modules ?

What modules are known users of ppaddr hacking ?

With the hooks that have been added over time,
do we now have a better way to provide what ppaddr does ?

Of course, theres room to discuss the whole notion;
is 20% reduction in opcode memory likely to reduce cache
pressure more than the increasing cache-temp of the
PL_ppaddr[] array, which is currently hardly used ?

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About