Both HHVM and PHP7 use PCRE's JIT compiler to compile regular expressions into efficient byte code. Compilation is pretty expensive, and PCRE doesn't cache anything for you: it's up to the caller to decide whether (and how) to store and reuse the bytecode and other JIT data for a particular pattern. So while PHP7 and HHVM use the same library to execute patterns, each runtime has its own cache implementation.

As far as I know, we've never attempted to analyze the efficiency of the pattern cache and tune it for MediaWiki. There may be some low-hanging performance optimization opportunities there, since MediaWiki spends a lot of resources on regexp execution.

PCRE also allocates a block of 32K on the heap to use as a stack for its regexp virtual machine. The size of the stack is tunable, and in the past there was some discussion on the PHP internals list about increasing it, driven partly by this bug: https://bugs.php.net/bug.php?id=70110. The discussion died out, partly due to lack of real-world data. So that's another ripe target for instrumentation and tuning, in my opinion.

AFAIK there's no way to instrument this from PHP code. We'd either have to modify the runtime to collect and export PCRE JIT metrics. Alternately this could be done using 'perf' to trace PCRE function calls. On recent-ish Intel processors this can be done using LBR (https://lwn.net/Articles/680985/) and the runtime overhead is low enough that you can sample in prod.

All of the above assumes the WMF doesn't disable the PCRE JIT. If it's disabled then obviously the first thing to look into is whether turning it on could be beneficial.