HHVM: a Hack virtual machine with a JIT

What HHVM is for, and who ends up using it

HHVM is an open-source virtual machine for executing programs written in Hack. The README frames the design goal in one line: it uses a just-in-time compilation approach, which the project describes as achieving superior performance while keeping development flexibility. That combination is the whole pitch. A JIT lets the runtime specialize code as it runs rather than paying full interpretation cost, and it lets developers keep a dynamic language rather than moving to a compiled one.

The audience follows from that. If you are writing Hack, HHVM is the runtime the language targets, and the repository ships the typechecker alongside it in hphp/hack. If you are running PHP, the README's framing is narrower: HHVM executes programs written in Hack, and PHP appears only in the PHP and Zend licences rather than in the introduction. The repository is large and C++-heavy, with CMake/, third-party/, build/, ci/ and configure at the top level, which tells you the primary consumers are people willing to deal with a native toolchain.

The runtime, the typechecker, and the web layer

The repository layout separates four concerns. The hphp/ directory holds the VM itself plus hphp/hack, the typechecker, and hphp/hsl, the Hack Standard Library. The build system is CMake driven, with configure and CMakeLists.txt at the root and a third-party/ tree for vendored dependencies. CMake/ holds the project's own CMake modules. That is the architecture visible from the outside: one large C++ codebase, a separate typechecker component, and a standard library, each with its own licence file.

On the serving side, the README is explicit that HHVM is not a webserver you point at arbitrary traffic. It says HHVM should be used together with a webserver, either Proxygen, which is built in and described as easy to deploy, or a FastCGI-based webserver on top of nginx or Apache. So the data flow is either Proxygen accepting requests directly inside the HHVM process, or an external nginx or Apache process speaking FastCGI to HHVM. The README's website instructions end by pointing at http://.../main.hack, which suggests the entry file convention is a .hack file rather than an index.php.

Installing HHVM and running a first script

The README does not list package manager commands. It points at two paths: a prebuilt package, documented under the installation introduction, or compiling from source, documented under building from source. It also links a getting started guide for newcomers. Because the README gives no distro-specific commands, the honest first step is to open the installation page and pick the path that matches your platform.

Once hhvm is on your PATH, the README states that standalone programs run by passing them to the binary. The example it gives is exactly this:

hhvm example.hack

If that script prints output, you have a working runtime and the JIT is doing its job without any webserver involved. This is the fastest way to check that an install succeeded before you involve nginx or Proxygen.

For a website, the README's sequence is: install a webserver, install the HHVM package, start the webserver, then start HHVM with the init script, then visit the site at a main.hack path.

sudo /etc/init.d/hhvm start

Note what that command implies: an init.d script, so a SysV-style service rather than a systemd unit. On a modern distribution you may need to check how the package wires the service up, because the README does not describe a systemd equivalent.

Where HHVM is the wrong choice

The README never claims PHP 8 compatibility. It describes HHVM as a virtual machine for Hack, and PHP appears in the licence section, not in the feature description. If your codebase depends on PHP 8 language features or on extensions that expect the standard PHP engine, the README gives you nothing to rely on. Treat PHP execution as something to verify against your own code, not as a documented guarantee.

The webserver constraint is the second boundary. HHVM does not serve HTTP by itself in the README's description; you need Proxygen or a FastCGI setup behind nginx or Apache. If you wanted a single binary that terminates TLS, routes, and serves static files, this is not that, and the README does not pretend otherwise.

The third issue is the release history. The most recent releases listed are HHVM-3.15.0, HHVM-3.9.9 and HHVM-3.12.8, all dated 2016-09-28. That is a decade of release tags without a newer one in this list, even though the last push to master was on 2026-11-02. Whatever is happening on master, the tagged release channel visible here stopped a long time ago, and anyone who plans to pin a version should confirm what artifacts actually exist for their platform rather than assuming a current tagged build.

HHVM against the standard PHP runtime

The obvious alternative is the reference PHP interpreter from php.net. The difference in approach is the execution model. PHP's engine compiles to opcodes and executes them, with optional opcache and a JIT added in recent major versions. HHVM compiles Hack and PHP to its own bytecode and JIT-compiles hot paths, which is why the README leads with performance as the reason to exist.

The trade-off is ecosystem distance. The reference runtime is what most PHP libraries, extensions and deployment guides assume, and the README does not claim HHVM matches it. HHVM's advantage is the pairing with Hack: you get a gradual type system, the hphp/hack typechecker, and hphp/hsl in the same repository, with a runtime designed for the same language. If you are not using Hack, that advantage largely disappears and you are left comparing a JIT runtime against the one your dependencies were tested on.

Licence, maintenance and the cost of staying current

The licence situation is split, and the README says so plainly. HHVM as a whole is licensed under the PHP and Zend licenses except as otherwise noted. The Hack typechecker in hphp/hack is under the MIT License, and the Hack Standard Library in hphp/hsl is under the MIT License, again except as otherwise noted. The repository confirms this with LICENSE.PHP and LICENSE.ZEND at the top level and separate LICENSE files inside hphp/hack and hphp/hsl. The GitHub metadata reports the overall licence as NOASSERTION, which is consistent with a multi-licence tree rather than a single SPDX identifier. If you redistribute HHVM or embed the typechecker, check which files you are shipping and under which of these terms.

Maintenance is harder to read. The repository is not archived and the last push was on 2026-11-02, so work is landing on master. But the release list ends in 2016. Upgrade cost therefore depends on whether you build from source, in which case you track master and absorb C++ build churn across CMake/, third-party/ and build/, or whether you rely on prebuilt packages, in which case you need to confirm what the package channel currently offers. The README does not document rollback, version pinning, or a support window, so those are questions for the installation documentation and the packages themselves.

Editorial conclusion

Adopt HHVM if you write Hack and want the typechecker and runtime from the same repository, and you are prepared to build from source or use a prebuilt package whose availability the README does not spell out. Do not adopt it as a drop-in PHP 8 replacement on the strength of the README alone, which never claims parity. Before committing, verify three things yourself: that a prebuilt package exists for your distribution and version, that your webserver path is Proxygen or FastCGI as the README describes, and that the licence situation for the parts you use is acceptable to you, since the top-level LICENSE files cover PHP and Zend while hphp/hack and hphp/hsl carry their own MIT terms.

Frequently asked questions

Official sources

1. facebook/hhvm on GitHub
2. Issues
3. Project website
4. README
5. Releases