The HHVM team has just wrapped up its planning for the first half of 2014. We’d like to share our plans, providing you a bit of context.

2014 Themes:

  • Open Source

  • Increase Web Efficiency

  • Make HHVM Hackable

Open Source goals:

  • Increase community participation and adoption

  • Move to open development

    • Figure out a way to have all non-Facebook specific HHVM development done in the open.

We’ve been making steady progress on HHVM’s compatibility with PHP in the wild, but we still have a lot of work ahead of us. We’re using unit test pass rates as a proxy for success measurement, but you can help by adding HHVM to your Travis configuration, and reporting bugs and issues through GitHub. We are resourced to help support a couple of major HHVM deployments, which we hope has the side effect of exposing us to “non-Facebook” deployment and maintenance challenges.

We are also going to push for a more open development model, with the goal of increasing our community participation. We’ll have more to say on what this means later on. Stay tuned!

Increase Web Efficiency:

  • Further CPU time reduction

    • JIT improvements (including region compiler work)

    • HHBBC (HH bytecode-to-bytecode compiler)

    • Code and data layout optimizations

    • Lockdown improvements

  • Reduce Memory

    • Memory bandwidth reductions

    • Working set reductions

    • Ship a memory profiler

  • ARM64

    • 25% bytecode coverage on simulator
  • Prototype LLVM integration

We’ve set very aggressive efficiency goals for the half that we hope to achieve through a range of JIT compiler projects. We hope these translate into wins for a variety of PHP workloads. We’re shooting for wins via the region compiler project, which is a compilation strategy that stitches together multiple basic blocks into larger chunks of code. This means that the current optimization passes we have in place can do a better job at identifying and exploiting optimization opportunities.

HHBBC (HipHop Bytecode to Bytecode compiler) is essentially a redesign and reimplementation of something we already have: a type inference pass. Right now we do type inference during the AST (Abstract Syntax Tree) generation phase, but we think we can do a better job of this at the bytecode level while giving us option value to augment bytecode with richer type information through tooling and offline static analysis. Having more type information on hand means generating faster and more specific code – it’s like “peering in to a dynamic program, and pulling out its static equivalent”.

We’re also planning on really knuckling down on memory consumption: both total working set and memory bandwidth usage. Reducing both will inevitably give us CPU time wins (a lot of our CPU time is spent waiting for memory requests) and will allow us to deploy to servers with a smaller memory footprint. All requests start with a fresh heap, add and subtract to it over the lifetime of the request, and then throw it away. As we increase RPS (inevitable side-effect of better quality code generation) we also increase bandwidth pressure on the memory subsystem. We want to make sure that the memory bus does not become a bottleneck.

Hackable HHVM:

  • “Hackers guide to HHVM” 50% complete

  • Reduce complexity in [hphp/compiler](

  • 100% conversion to HNI extension interface

  • Remove legacy tracelet compiler features (analyzer/translator, HHBC guard relaxation, etc.)

Hackable HHVM really means “move faster”. We want to ship better documentation to help you guys (and it really helps us too…) get hacking on HHVM. One significant part of the “Hackable HHVM” theme is moving all of our internal extensions over to the HNI interface which is a super fast lightweight way of building extensions for HHVM.

An Exciting Road:

The Road Ahead

Clearly it’s going to be a big half in terms of technical agenda, and probably our biggest in terms of open source engagement. We’ll be attending conferences, shipping code, getting faster and having fun this year.

Please continue your awesome effort of using and contributing to HHVM, and discussing all things HHVM on IRC at #hhvm. We looking forward to having you join us for the ride in 2014 and beyond.


  • Vincent DM: First of all, thanks for building this great software. I'm eager to start using it, but the major obstacle for me right now is debugging. I don't find the existing debug tool very convenient. Would it be possible to make it compatible with XDebug's API? that way, I could continue using existing tools like PHPStorm. Thanks!
  • Oli: Impressive Roadmap! Thank you for this huge open source engagement.
  • Christopher Svanefalk: Hard to put into words how awesome you guys are, it's going to be extremely exciting to see how the project moves forward the coming months! If you ever come to Gothenburg - I am buying you all a round of our local brew if you want it. You have it in writing!
  • Evert: Maybe also find a better name for 'Hack' ;)
  • Daniel Urich: Hope you include other database support like Oracle.
  • Kapil: Documentation for 'Hack' .. its a "game changer" of sorts, IMO
  • Brett: I have to agree about finding a better name for 'Hack'. Trying to google something like 'hack php' or any other similar phrase grabs a completely unrelated set of results as you could guess.
  • Michael: Why a better name for 'hack'? It's descriptive of their intent. Thanks for the roadmap. It's good to get some planning messages like this to give some community confidence in the project. Really rooting for this project to help boost PHP!
  • Sami Onur Zaim: I am looking forward to use Joomla with Hhvm. So far I am not able to pass final installation screen because of 'mbstring.language = neutral' requirment in .htaccess file. Also compiled hhvm 3.0 packages on Centos would be nice.
  • Dwayne Lafleur: The big obstacle for us using for most of our development is it's lack of XDEBUG or DBG support. We really need to be able to have similar debugging capabilities as other languages or the changes that reduce errors in the codebase are counteracted by lack of proper debugging support.