|Do you know where your variables are?|
Everytime I've looked at that regex ive thought the same thing: what a strange regex to use for a comparison benchmark.
One optimisation that is missing from pre 5.9 Perl is that there is nothing to convert /x|y|z/ into the far more efficient /[xyz]/.* If javas regex engine does contain a compile time optimisation of this sort its almost guaranteed to run faster than released version of Perl. On 5.9 and later it would be handled somewhat better as a TRIE which would be much faster than before, but still not as efficient as if it had been a char class. (Any C programmers out there interested in a neat hack, converting TRIE regops with only one row in their table to proper char class nodes would be cool).
This factor coupled with the fact that he doesnt actually show what strings he matched against make me somewhat dubious of the value of his assertions.
Without looking at the optimisations built into the Java regex engine (which no doubt they do not release) its hard to say why Perl would be slower than Java. I personally wouldnt necessarily assume that it was the backtracking logic that was at fault without a better understanding of the test cases that he used for his timings.
* Update: IOW its probably not fair to penalize a system for performing one task inefficiently when there is an equivelent construct that is efficient, unless in the context of an overall comparison.