This contains some helpful hints and frequently asked questions about HHVM.
For a history of what is now HHVM, please visit our Wikipedia page.
Facebook's entire site runs on HHVM (desktop, API and mobile), both in development and production.
- Linux: HHVM has official Linux support on flavors of Ubuntu and Debian.
- Mac OS X: HHVM has experimental support on Mac OS X.
- Windows: HHVM is currently being ported over to Windows.
- For a discussion about HHVM and its benefits, please see this PHP UK Conference 2013 presentation.
- For a deep dive into the HHVM internals, please see this QCon 2012 presentation.
- Other information can be found in the references of our Wikipedia page.
- Presentations from the Hack Dev Day 2014.
New users may want to try our high-level overview getting started guide.
You can find more detailed installation information here.
At Facebook, HHVM is pushed every 2 weeks (as you can see from the NEWS file), but having everyone in the world update every 2 weeks would lead to too much testing and churn. After asking around this seems to be a good compromise between churn and getting new features. In the future we could switch to every 6 weeks or 10 weeks or any multiple of 2 that the community likes.
- Facebook: HHVM has run www.facebook.com in production since 2013.
- WordPress: hhvm.com, a WordPress blog, is running on HHVM.
- MediaWiki: MediaWiki installations can run on HHVM, and Wikipedia has run on HHVM since 2014.
- Most other PHP frameworks. We run internal regression testing on 20 of the most popular ones to ensure continued compatibility.
Here are some other places HHVM is being used: https://github.com/facebook/hhvm/wiki/Users
There are definitely issues that need to be addressed with HHVM. The HHVM GitHub issues describe bugs that exist with the current implementation.
The HHVM team is working really hard to enhance functionality and fix bugs that currently exist.
Please submit an issue.
For real-time discussion, the team tends to hang out in #hhvm on IRC during working hours US Pacific time (and knowledgeable community members are often around at other times too).
Proxygen is full featured, very fast web server and generally easier to get started with out of the box. FastCGI is a bit more configurable, but requires a separate web server (e.g., nginx) on the front of it.
Here is the list of supported extensions.
The HHVM wrapper provides a simpler interface to the HHVM binary for many common options (e.g., running in server or interp mode, compiling a repo-authoritative repo, dumping bytecode, running gdb). It is located at
hphp/tools/hhvm_wrapper.php. You can see all of the available options by running:
/var/run/hhvm/hhvm.hhbc and run your program again
There can be many reasons. And it is tough to diagnose that general question. It could be a bug in HHVM. It could be that you need to increase the size of your translation cache. Or it could be other factors.
The best thing to do is file an issue and at minimum give us the problem and a stack trace. You will get a much faster and more quality response if you also provide us as small as possible reproduction case with PHP or Hack code.
The HHVM JIT needs time to warm up. The warmup usually occurs somewhere on the order of 10-11 requests, at which point the JIT has performed its optimizations and off we go at peak speed.
So, in HHVM server mode, you start out by running the first couple requests in interp mode to get things primed. You don't really want to be optimizing the first few requests since that is when initialization is occurring, caches are being loaded, etc. Those code paths are generally cold later on.
After the first few requests, the JIT is on its way to optimizing.
It is advisable, but not required, if you are running an HHVM server to send the server some explicit requests that are representative of what user requests will be coming through. You can use
curl, for example, to send these requests. This way the JIT has the information necessary to make the best optimizations for your code before any requests are actually served.
Have you seen an error like this?
Fatal error: Syntax only allowed in Hack files (<?hh) or with -v Eval.EnableHipHopSyntax=true
If you have a
<?php file where you want to enable Hack syntax in repo authoritative mode, you have to make sure that you specify
hhvm.force_hh=true in both the repo compilation stage and when running code from the repo.
For example, if you have a file named
enable-hack-in-php.php and you wanted to create a repo from that file and run it, you would need to do something like the following:
# compilation of repo stage % hhvm --hphp -t hhbc -v AllVolatile=true -dhhvm.force_hh=true `enable-hack-in-php.php` # execution stage; hhvm.hhbc file location will vary % hhvm -dhhvm.force_hh=true --file 'enable-hack-in-php.php' -vRepo.Authoritative=true -vRepo.Central.Path="/tmp/hphp_RdsESQ/hhvm.hhbc"
This isn't necessary when using Hack syntax in Hack (
<?hh) files, only when wanting to use Hack syntax in PHP (
<?php) files, which is unusual.
You may have hit the sorting inconsistency.
It is not safe to rely on the system's timezone settings. Please use the date.timezone setting....
This should be fixed in HHVM 3.12+ with this commit, but if you are using an earlier version, then update your
/etc/hhvm/php.ini file to add:
date.timezone=America/Los_Angeles # or your appropriate timezone
Fatal error: /home/user/sites/www/index.php appears to be a Hack file, but you do not appear to be running the Hack typechecker.....You can also set hhvm.hack.lang.look_for_typechecker=0 to disable this check (not recommended).
This means you are trying to run files with HHVM, either local or via server requests, that are
<?hh files, but are not being typechecked by
Make sure there is an
.hhconfig somewhere in the root of your project.