PAR uses B::Bytecode if you want compiled code

Given the CAVEATS in PAR::Filter::Bytecode:

This backend exhibits all bugs listed in B::Bytecode, and then some. Bytecode support is considered to be extremely fragile on Perl versions earlier than 5.8.1, and is still far from robust (as of this writing).

I'm actually surprised that anyone uses that facility. I guess that if anyone cares enough to keep B::Bytecode going after it has been removed from the core then they will step up to the plate to maintain it independently on CPAN.

The B suite of modules are always going to suffer from accelerated bit-rot if no-one is interested in looking after them because they have to keep pace with the changes in the internals and not just the published API. Whilst they have been in the core it appears people have been doing just enough to keep them passing the tests but no more (a reworking three years ago not withstanding:) certain comments on p5p would suggest that some changes in bleadperl have probably broken stuff that is not being tested for.

Of course the very fact that the module is tied so very closely to perl's internals and thus almost certainly to specific version ranges would probably suggest that it would need a massive overhaul if it were to be maintained on CPAN and work across a range of Perl versions, this in itself might be sufficient disincentive to anyone volunteering to do so.

A cursory examination of perlbug would seem to indicate that there have only been a handful of bug reports against B::Bytecode ever, which either indicates that there are no bugs (unlikely) or people just aren't using it enough to discover any bugs - and given the EXPERIMENTAL label scattered throughout the documentation, I would suggest the latter.

/J\