On the HHVM blog (Facebook's HipHop Virtual Machine project) they've posted about support for PHP 7 features that they've been working into HHVM and Hack to support backwards compatibility with this latest major version of the PHP language.

For those that haven’t been following along, the next version of the PHP language, version 7.0.0, was very recently released. Those of us working on HHVM offer our congratulations to all the contributors to this latest release! We’re all really excited to see this release come out the door, and for what it means for the future of PHP.

The release has implications for HHVM as well. [...] The HHVM project is committed to continuing to support the evolving PHP language, and as such we are proud to announce that the current nightly releases have support for all major PHP 7 features, and the upcoming 3.11.0 stable release will be the first release of HHVM with support for the major PHP 7 features.

There are some backwards compatibility issues that PHP 7 introduced but the HHVM project has opted to support both the PHP 5 and 7 users simultaneously. This is made as low friction as possible either through silent compatibility or though a hhvm.php7.all ini configuration setting.

The Facebook HipHop Open Source blog has posted a case study from Box about their migration to HHVM and some of the challenges and benefits that came along with it.

Reducing latency and increasing the capacity of our infrastructure have always been top priorities at Box. We strive to deliver the best possible user experience in the most efficient manner, and historically our choice of PHP hasn’t aligned well with these goals. I'm very happy to report that we've recently made very significant strides toward these two ideals by successfully deploying HHVM (the HipHop Virtual Machine) as the exclusive engine that serves our PHP codebase. In the rest of this post, I will detail how we use PHP, how HHVM works, the challenges we faced migrating to HHVM, and the remarkable performance wins it provides.

The post talks about how central PHP is to their overall technology stack and how, despite the work being put in, the processing of requests was starting to be a bit too much. In came the HHVM and some discussion about how it might be used there at Box. They started a yearlong effort to migrate their entire stack to HHVM especially since HHVM has almost reached parity with the PHP language itself. They talk some about the differences in design between the two and how the migration changed their deployment process. They also cover some of the other interesting things that come with a major migration including phased rollout and host-based conversion methods. Finally they share some of the statistics around the performance of the end result, including the better response times and reduced CPU graphs.

On the Etsy "Code as Craft" blog they've posted an article about their experiences in experimenting with HHVM at Etsy and some of the differences it makes.

In 2014 Etsy’s infrastructure group took on a big challenge: scale Etsy’s API traffic capacity 20X. We launched many efforts simultaneously to meet the challenge, including a migration to HHVM after it showed a promising increase in throughput. Getting our code to run on HHVM was relatively easy, but we encountered many surprises as we gained confidence in the new architecture.

They start with a brief overview of what HHVM is for those that aren't sure and talk about where their focus was in these experiments. They list out some of the main reasons for trying out HHVM and the role of concurrency in their current application. They started with the "minimum viable product" and compared benchmarks between PHP 5.4 and HHVM on several endpoints. They also show how they "teed" incoming requests to both servers to ensure that the responses were the same across both. They also talk about using employee-only traffic and the overall statistics for when they released the HHVM version internally. They also talk about some of the undocumented features to keep an eye out for if you're thinking of switching: "warming up" the requests to align them in JIT memory, using perf(1) for profiling and the use of the HHVM interactive debugger (hphpd).

Similar to how the language specification was released for PHP a little while back, the HHVM team has announced a new specification for Hack, the language they've created as a part of the HipHop VM project that's similar to PHP.

When we announced Hack, we were very excited for the community to get their hands on a programming language that has helped Facebook engineers become more productive in their day-to-day development and became, alongside PHP, the language used when developing applications running on HHVM. At the time of release, we had documentation geared for the programmer using Hack to develop applications. However, we did not have official documentation for those that might want to create a Hack implementation of their own or something like a Hack conformance test-suite. This specification fills that gap. It is the document for the Hack implementer, and an excellent supplemental document for the Hack user.

The remainder of the post talks about some of the reasoning behind creating the specification, pointing to resources where you can help contribute and a few thanks to some of the people that worked on it.

In the latest post to the HHVM (HipHop VM) blog Sara Golemon recounts the journey of a thousand bytecodes and the process that it takes to decompose a PHP file and optimize it for execution in the HHVM environment.

Compilers are fun. They take nice, human readable languages like PHP or Hack and turn them into lean, mean, CPU executin’ turing machines. Some of these are simple enough a CS student can write one up in a weekend, some are the products of decades of fine tuning and careful architecting. Somewhere in that proud tradition stands HHVM; In fact it’s several compilers stacked in an ever-growing chain of logic manipulation and abstractions. This article will attempt to take the reader through the HHVM compilation process from PHP-script to x86 machine code, one step at a time.

The process is broken down into six different steps, each with a description and some code examples where relevant:

• Lexing the PHP to get its tokens
• Parsing the token results into an AST (and optimizing it along the way)
• Compilation to Bytecode
• HHBBC Optimization
• Intermediate Representation
• Virtual Assembly
• Emitting machine code

The HHVM (HipHop VM from Facebook) has released an update on their blog today discussing some of the long term support they plan to provide for the project and what kinds of things it will involve.

HHVM is known for its very intense and quick development pace: currently we ship to GitHub the exact same code we use to run the Facebook site within minutes of every commit, and we release a full version every 8 weeks. That is great and at the same time scary if you are trying to build a business or infrastructure around it. The HHVM team at Facebook understands that in order to reach every corner of the PHP landscape our users need to have some sort of commitment, in order to plan their deployments accordingly and to know how upstream will react to security and stability fixes in already released versions, for example.

Starting with HHVM v3.3, they'll be supporting two major versions at all times. They provide a table of versions and dates to give you an idea of when the support coverage period is and when they'll end. There's also some discussions about the packaged released for the various linux distributions and what kinds of updates might be included in the long-term support (LTS) updates.

On the HHVM blog today they've announce the release of the latest version of the popular project, version 3.1.0. This version fixes a few issues (including a segfault) and crossed into their semi-annual "lockdown" to work directly on the project.

If you remember last time we focused on framework unit tests, performance, and growing beards. This time, our frameworks were in good shape thanks to Fred and our Open Academy students, but our github story was not as pretty. At the start of lockdown we had 60 pull requests and nearly 450 issues. So our focus this time was github health and of course as always, perf.

In the end they closed out 251GitHub issues and made things 16% more efficient in the process. They list out some of the updates in this release including:

• Support for PHP 5.6 variadic ...$args syntax for func declarations
• Over 400 ini settings you can use to configure various things
• Fixes for several security issues including CVE-2011-2202 and CVE-2014-2270

You can grab this latest release from the pre-build packages page on the GitHub project account.

On the HHVM blog today a new post talks about some of the work they've been doing to introduce one of the common PHP extensions, MySQLi, into the HHVM system. The post walks you through some of the process the author followed to work up the implementation.

To prepare for what was to be my big project, I rewrote the ini parser to better match Zend. [...] After warming up with the parser, I was ready to start my big project: implement MySQLi. This has been a long requested feature for HHVM. And, this extension is required to help meet our compatibility goals.

He walks you through some of the preparation steps for the work integrating the extension and the tools used for these initial steps. He briefly steps through the actual implementation and the testing of the feature (and some changes made to allow the tests to run faster). He mentions a few roadblocks hit along the way, the current status of the effort (182 passing tests, 114 failing) and some of the missing pieces yet to be worked.

In their latest post the HHVM project (of Facebook) has laid out the next six months ahead for the development and progression on the project. In it they talk some about their "themes" and overall Open Source goals planned for the first part of 2014.

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. 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!

They also cover some of the work being done to increase the overall efficiency, reducing CPU time and memory consumption. There's also mention of work being done on a guide to "hacking" in the HHVM, reducing some complexity in the compiler and the conversion to a full HNI extension interface.

Juan Treminio passed along a note about his GUI-based virtual machine builder PuPHPet and some recent advancements in what it supports.

PuPHPet just added support for HHVM via FastCGI for Apache/Nginx and needs your help to create a VM and report any bugs encountered to make the experience as smooth as possible.

PuPHPet makes creating Vagrant/Puppet configurations much simpler and does a lot of the hard work for you. The project is also open sourced on GitHub so you can always add support for anything you might not see.