What's the status of the JIT?

Hi brent, your mail went straight to spam, i don't really know the cause
but most people were unable to see this issue.

Kindly restructure the message and resend.

On Fri, 14 Nov 2025, 10:49 am Brent Roose, brent.roose@jetbrains.com
wrote:

Hi internals

I'm wondering about the state of PHP's JIT these days. I understand that
Dmitry is still working on his standalone JIT IR framework [1] that's being
used by PHP, and that Arnaud is maintaining it from the Foundation/PHP
side? In my own benchmarks, done in PHP 8.0 and PHP 8.4; I cannot seem to
get any meaningful performance gain from the JIT in web applications or in
tools like PHPStan. [2][3][4]

The question I'm left with is whether the JIT is worth the hassle?
Assuming the JIT's existence impacts the complexity of internal
development, I wonder if it wouldn't be better to deprecate it in a future
PHP version? To be clear, I'm assuming the JIT impacts internal development
— maybe that's wrong? Perhaps I'm missing a real-life use case that
benefits significantly from the JIT as well?

Kind regards
Brent

[1] https://github.com/dstogov/ir
[2] https://stitcher.io/blog/jit-in-real-life-web-applications
[3] https://youtu.be/2Njl1ZiCXIk?si=qytMIVxt0oTC3b1F&t=1057
[4] https://www.youtube.com/watch?v=5ResKrAnpBw

Hi Brent,

I'm wondering about the state of PHP's JIT these days. I understand that Dmitry is still working on his standalone JIT IR framework [1] that's being used by PHP, and that Arnaud is maintaining it from the Foundation/PHP side? In my own benchmarks, done in PHP 8.0 and PHP 8.4; I cannot seem to get any meaningful performance gain from the JIT in web applications or in tools like PHPStan. [2][3][4]

To be fair, the first web benchmark in [2] shows a 9% improvement with
the tracing JIT enabled. But the benchmark seems very unstable: The
second run gives a widely different number for the baseline, but I
would expect that number to be very close to the first run.

However I confirm that the JIT provides no improvements on PHPStan at
all currently.

The question I'm left with is whether the JIT is worth the hassle? Assuming the JIT's existence impacts the complexity of internal development, I wonder if it wouldn't be better to deprecate it in a future PHP version? To be clear, I'm assuming the JIT impacts internal development — maybe that's wrong? Perhaps I'm missing a real-life use case that benefits significantly from the JIT as well?

If performance is an important feature, then we need a JIT in the long
term. Other VMs have shown that JITs can have spectacular performances
in practice. The reason our JIT is not bringing much benefits yet is
that it's still in a very early stage, especially on the frontend
side. The alternative would be to rely entirely on interpreter
improvements, but it's already state of the art, and we are way past
the point of diminishing returns: it's unlikely that we can make as
much improvements with the interpreter alone than with a JIT. Also
it's likely that work on the JIT has a better cost/benefit ratio at
this point.

Regarding the impact of the JIT on internal development, I believe
that it's relatively low:

• The JIT is known to be a bit unstable yet, and there are occasional
  JIT bug reports, but these affect only the JIT and deployments with
  JIT enabled
• Changes to the VM are likely to require changes to the JIT as well,
  but this is not the majority of the work
• Language changes, such as those proposed in RFCs, often require JIT
  changes as well. But RFCs are not required to implement JIT changes
  before voting, so this only adds overhead on accepted RFCs. This
  represents a very small fraction of the work required on an RFC.
• Other changes don't usually need to care about the JIT

Best Regards,
Arnaud