HHVM 3.20 is released! This release improves compatibility with PHP7, and adds a couple new features. Packages have been published in the usual places; see the installation instructions for more information.
HHVM 3.19 is released! This release has some exciting new experimental features. Packages have been published in the usual places; see the installation instructions for more information.
HHVM’s JIT is responsible for translating sequences of HipHop Bytecode (HHBC) into equivalent sequences of machine code in order to execute PHP code as efficiently as possible. When running in server mode, HHVM shares this generated code across the many different threads executing PHP requests. Up until about a year ago, the JIT had a global “write lease,” which prevented multiple threads from running the JIT concurrently. This decision was made primarily to improve the layout of the generated code, but also to reduce implementation complexity. The project was still unproven, and we had to balance between shipping a perfect system and never shipping anything.
HHVM is now fully-functional on ARM hardware! This post tells the story of how our ARM port came to be.
Our initial version of the HHVM JIT didn’t use profile-guided optimizations, and we suspected that we were leaving performance on the table because of that. After adding HHIR and beefing up the JIT backend in 2013, a couple of us embarked on the journey of building a profiling mechanism and leveraging it to improve the JIT’s optimizations and HHVM’s performance.
HHVM 3.18 LTS is released! This version will be the last to support GCC 4.8 and Ubuntu 14.04 Trusty. Packages have been published; see the installation instructions for more information.
We recently finished our start-of-the-year planning, and here are some of the HHVM open source goals for the first half of 2017. Want to influence our priorities for the coming months? Fill out this survey .
The next LTS release of HHVM has been cut and packages are now available for Ubuntu 14.04, 15.04, 15.10, and 16.04; and Debian 7 and 8. This release replaces the 3.9 LTS and brings with it a host of improvements and new features.
We are happy to announce our next generation of Hack and HHVM user documentation available at http://docs.hhvm.com.
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.
“…use collections whenever and wherever possible. However, 100% usage of collections is obviously not realistic given how much arrays are used in various codebases …there just may be legitimate use cases for an array”
This is the guidance given to Hack developers on using arrays. While we still advise using collections whenever possible, in hindsight there are more “legitimate use cases” for arrays than we first believed. With that in mind, the team is planning on improving arrays so they are better supported in Hack. We’ve opened a number of issues on GitHub (#6451, #6452, #6453, #6454, #6455) with our initial plans. Since this would be a significant change in the language we are looking for feedback from the community. Before diving into what we are thinking of building, let’s take some time to examine the problem we want to solve.
One of the most common questions we get about HHVM is why we don’t use LLVM for code generation. The primary reason has always been that while LLVM is great at optimizing C, C++, Objective-C, and other similar statically-typed languages, PHP is dynamically typed. The kinds of optimizations that provide huge performance benefits for static languages tend to be less useful in dynamic languages, or at least overshadowed by all the dynamic dispatching that’s done based on runtime types. We knew that there was probably something to be gained from using LLVM as a backend, but there were many larger opportunities go after first.
$ brew tap hhvm/hhvm $ brew install hhvm
We’re happy to announce that HHVM 3.8.0 is finally available. You can, as always, try one of our prebuilt packages for Ubuntu and Debian, or build from source. (As of this writing, the packages are still building, so if a 3.8.0 package isn’t available for your supported distro, hold tight!)
We just released HHVM versions 3.3.7, 3.6.5, and 3.7.3 which fix CVE-2015-4663, a serious issue affecting SSL/TLS certificate validation. Note that the issue affects
file_get_contents, the stream API, etc, but does not affect anything using the cURL API directly.
In PHP, traits are a mechanism of code reuse that, while very powerful, are also difficult to type check both efficiently and exhaustively. In this post we’ll dive more deeply into the reasons for that and see how Hack solves those problems, allowing you to use traits in a safe way without limiting their expressiveness.
The HHVM team has concluded its first ever open source performance lockdown, and we’re very excited to share the results with you. During our two week lockdown, we’ve made strides optimizing builtin functions, dynamic properties, string concatenation, and the file cache. In addition to improving HHVM, we also looked for places in the open source frameworks where we could contribute patches that would benefit all engines. Our efforts centered around maximizing requests per second (RPS) with Wordpress, Drupal 7, and MediaWiki, using our oss-performance benchmarking tool.
Hack has recently enhanced its generics with two features: variance annotations and
super type constraints. In this post, I’ll explain how they work and why they were added.
It’s that time of year again! Next week the HHVM Open Source team is beginning a lockdown. The next two weeks will feature beards, long hours, and performance wins. We’re excited to announce that this will be our first ever open source performance lockdown.
As some of you have no doubt noticed, HHVM 3.7.0 has been out now for a few days. It comprises the internal “Earle”, “Fry”, “Gadd”, and “Harris” releases.
We’d like to get more developers in the community using Hack. But we know there’s been something lacking: a good, consolidated resource for learning Hack and getting the most use out of it. We have documentation online, but it’s more of a reference than a tutorial.
Dan Miller, an engineer at Etsy, wrote an extensive blog post detailing Etsy’s transition to HHVM on some of their production servers.
Announcing the immediate release of HHVM 3.6.0. built upon our internal “Ballmer”, “Colbert”, and “Ditko” releases. This represents our second official LTS release following 6 months after the release of HHVM 3.3.
Today we are excited to announce the availability of the initial specification for the Hack programming language.
The next HHVM release, 3.6, is on the horizon. We expect it to be released at the very end of February or in early March. It’s going to be a big release. Not only will it be our second release with long-term support, but it will contain several exciting new features – and lay the groundwork for continued development later this year.
We have released HHVM 3.5.0 – get it while it’s hot! It contains updates from the “Xzibit”, “Yelawolf”, and “Z*” internal branches – the last of the 2014 rapper theme. It also contains updates from the “Austin” internal branch, the first of the new 2015 theme. (Anyone want to guess at what the new theme is?)
If you’ve been watching our GitHub wiki, following us on Twitter, or reading the wikitech-l mailing list, you’ve probably known for a while that Wikipedia has been transitioning to HHVM. This has been a long process involving lots of work from many different people, and as of a few weeks ago, all non-cached API and web traffic is being served by HHVM. This blog post from the Wikimedia Foundation contains some details about the switch, as does their page about HHVM.
I just pushed HHVM 3.3.2 (and 3.4.2) onto the Debian and Ubuntu repositories. It contains fixes backported from PHP for several security issues that HHVM was also vulnerable to, as well as a fix for CVE-2014-9370, which is a header injection issue affecting only the deprecated built-in webserver. Most users of HHVM use FastCGI, which was not affected by CVE-2014-9370.
For several months now, Hack has had a feature available called
async which enables writing code that cooperatively multitasks. This is somewhat similar to threading, in that multiple code paths are executed in parallel, however it avoids the lock contention issues common to multithreaded code by only actually executing one section at any given moment.
Two big announcements back to back.
We have released HHVM 3.4.0, the first minor point release after our HHVM 3.3.0 LTS. This branch contains updates from our T-Pain, Ultramagnetic, Vanilla Ice and Will.i.am internal releases.
We’re proud to announce the first experimental release of the Hack Transpiler, a tool which allows projects that have converted from PHP to Hack to still make releases that target the PHP language. You can read the full announcement at code.facebook.com, or take a look at the documentation for the tool. It’s available in any nightly package dated today or later. It’s still experimental, so try it out and let us know how it goes!
A recent addition to Hack is the
__ConsistentConstruct attribute, which allows
new static() to be safely, properly typed. The need for this special attribute first requires some background in how method overriding and polymorphism normally work, and how constructors are special.
XHP is a great way to safely create HTML user interfaces from PHP or Hack. We love how extensible it is, allowing you to create your own pseudo-elements that are composed of more basic building blocks - ultimately a series of HTML tags. This solves a similar problem to partial templates in other systems. At its most basic level, XHP provides an XML-like syntax for creating stringable objects representing markup:
A lot has happened since we announced Hack. We’ve already highlighted our Hack developer day, as well as posting a series of community roundups (one, two, three) highlighting the projects that our amazing Hack community have been building.
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.
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.
As always, I’m really excited to see what our community has been building and saying, and really exited to share what I’ve seen with everyone!
The PHP language has been around for over 20 years and is clearly one of the most popular programming languages in the world. PHP is definitely the lingua-franca
of the internet for server-side web programming.
The HHVM community is awesome, particularly when it comes to directly helping us fix HHVM through pull requests. Until now, the actual pushing of commits (both our internal code and your pull requests) back to the master HHVM branch on GitHub has been a manual process, and takes more time than we would prefer (and I am sure may have frustrated you from time to time).
Since the last roundup, our community has continued to produce some really cool projects using Hack. I’m really excited to have another long list to share with all of you!
The next version of HHVM is hot off the press. After a few delays, we finally tracked down the segfault. We fixed it in master, but turning off the optimizations was safer for the release. Thanks for your patience.
In the weeks since the Hack open source launch and the Hack developer day, there has been a lot of information, code, blog posts, etc coming from our nascent community. To us on the team, it’s been incredible and encouraging to see the community reception to Hack. Here are some of the highlights of the things we’ve seen come out of our community. (And we almost certainly haven’t seen everything, so please let us know in the comments what we’ve missed!)
Earlier this year we set an ambitious goal of passing the PHPUnit test suites of 20 popular frameworks by the end of June; at the time, we were passing on only 6! With a huge amount of help from the community (especially our OpenAcademy students), we’re proud to have hit this goal more than 2 months early, and we have more frameworks expected to reach 100% shortly.
A few weeks ago, the Hack language was launched to the world. Yesterday, we held the first Hack Developer Day in Menlo Park, California. 150+ Members of the PHP and developer community came to Facebook headquarters and joined over 2000 people online for presentations by the engineers of Hack and HHVM. Afterwards we held a five hour hackathon, where the attendees worked with those engineers to write Hack code, either by converting current codebases or writing new code from scratch. By the way, bonus points to anyone who can decrypt the commit message used when Josh originally pushed Hack to open source.
We try our best to be a stable dependable runtime, but if you are reaching into the deep dark abyss of the PHP language, you might stumble upon a dark corner where we segfault or assert. First of all, we are sorry. Secondly, we would love you to report the issue, and if you can put together a small test case that is best. If it only reproduces under the full moon when you hold your head to the side and hop on one leg, then a stacktrace would be next best.
This is a fun one! :)
At our last major version bump (2.0.0), we basically became a whole new project. We switched from a “PHP -> C++” translator to a virtual machine. This version bump (3.0.0) is a much less dramatic code shift (we’re still a VM, don’t worry), but this time the big announcement is that we support a new language, Hack.
As you may have heard or seen already, the Hack programming language has been released for HHVM. Hack reconciles the fast development cycle of PHP with the discipline provided by static typing, while adding many features commonly found in other modern programming languages.
We haven’t done posts for point releases since our normal release schedule is so quick, but when there is a security fix we thought you should know as soon as possible.
HHVM has a large suite of unit tests that must pass in several build configurations before a commit reaches master. Unfortunately, this test suite passing doesn’t tell you if HHVM can be used for anything useful - so we periodically run the test suites for popular, open source frameworks.
I joined the HHVM team right before Christmas for a hackamonth (or, in my case, a hack-a-two-months).
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.
Increase Web Efficiency
Make HHVM Hackable
It is that wonderful time again for an HHVM release. We’re sticking to our 8 week release cadence to keep everything fresh and in your hands. Also, remember you can run the nightly packages if you want a bleeding edge feature.
If you just can’t wait to get your hands on the latest HHVM code, but you don’t want to spend the time to compile it, we have a present for you.
On November 4th, the HHVM team went on a 3-week performance and parity lockdown. The lockdown officially ended on November 22nd. Overall, this lockdown was a qualified success. Success was measured on 3 vectors:
Today, we are happy to announce FastCGI support for HHVM. FastCGI is a popular protocol for communication between an application server (e.g. running your PHP code) and a webserver. With support for FastCGI, you will be able to run HHVM behind any popular web server (Apache, Nginx, Lighttpd, etc). The webserver is in charge of handling all the intricate details of the HTTP protocol. HHVM is in charge of what it does best, running PHP code blazingly fast.
We released a new version of HHVM today. This one includes all the hard work from our lockdown (detailed post to follow) and the ability to use HHVM with FastCGI.
When the hhvm project was started almost 4 years ago, it had a two-part mandate: First, create a PHP JIT that could serve facebook.com at least as efficiently as hphpc, the PHP execution engine we were using at the time. Second, replace hphpi, the interpreter our PHP developers were using in their daily work. hphpc and hphpi were independent pieces of software with unintentional subtle differences in behavior and a significant maintenance burden. Unifying the execution engines used in production and development would make our jobs easier while giving the PHP devs a nicer experience at the same time. We had to find a balance between reaching these goals as quickly as possible and designing a system that could be extended and improved for many years after it replaced hphpc and hphpi. There were also concerns that just in time compilation might not be fast enough to keep up with Facebook’s aggressive deployment process. We were pushing a new version of the site to our fleet of web servers once every weekday, and the whole process took less than 20 minutes. We had to maintain that ability for hhvm to be a viable option. Taking all this into account, the initial JIT design was the simplest and fastest one that we thought had a good chance of succeeding.
The HHVM team, along with our wonderful open source contributors, is constantly trying to improve the runtime. We know, however, that there is work to do to run the world’s PHP code reliably and consistently.
Do you use heroku to host your PHP app and want to save 2x-10x dynos? Or serve user requests 2x-10x faster? I’m happy to announce that you can now use HHVM on heroku. You should clone your app and try it out before pushing to production as HHVM doesn’t support every possible use of PHP (yet).
We released a new version of HHVM today. A big change is that we are now packaging for many of the popular distros.
HHVM is a highly performant PHP runtime. In fact, it is nearly 40% faster than HPHPc, and only getting faster. For example, the HHVM team just rewrote the JIT to use an SSA intermediate representation (IR). HHIR (HipHop Intermediate Representation) is a strongly typed, SSA-form intermediate representation, positioned between HHBC (HipHop Bytecode) and machine code. It allows HHVM to perform optimizations that were very difficult to perform with the old JIT, using the context of the current runtime environment (e.g., reference counting elision).
HHVM’s JIT compiler allows it to execute PHP faster than Zend PHP in most cases, unmodified. However, we’ve gotten some interest from the community in HipHop-specific optimization tips, so I put together a few for this post.
The principle that underlies all of these tips is: write code that HHVM can understand without running. The more HHVM knows before the code runs, the more it can optimize.
First of all, hi. I recently joined the team as you could probably see from my plethora of commits to github. I first fixed up closures a bit and moved our “PHP tests in C++” to have one fewer language. I’ll be doing many exciting things for hiphop but I’ll be mostly caring about making it incredibly easy for anyone to use for any PHP code. So please bug me if it doesn’t run your favorite piece of code.
HipHop, if properly configured , will actually startup not one, but two http servers. The first, on port 80 by default, you’re already familiar with. Requests are translated to filesystem paths, and PHP files are executed to generate content. The other one, however, you might not have come across yet.
In this post, I’ll expand on a topic that I briefly mentioned in the footnote to my previous post: memory management.
Most modern programming languages, including PHP, have automatic memory management. Programmers don’t explicitly free the memory they allocate, and the language runtime does that for them. There are a variety of approaches that language runtimes can take to implement this, and they lie on a spectrum.
Been getting two or three spam comments/day. They don’t get through because moderation is enabled. They are an annoyance however, so I’ll be passing the annoyance on to you, dear reader, in the form of a very simple CAPTCHA.
As part of our drive to improve HHVM’s performance, I started looking into the general topic of builtin functions. Currently, HHVM is calling implementations of builtin functions that were originally written for HPHPc, the static compiler. We wrote compatibility wrappers around them for HHVM, to get it up and running as quickly as possible. We have evidence that this compatibility layer is hurting HHVM’s performance, so we’re looking at ways to reduce or eliminate its impact.
If you’ve looked at my previous entry Getting Wordpress Running on HHVM, you’ve already got a general idea for how to create a config.hdf file and get a web server up and running. Now you want to make sure it’s running as quickly, and efficiently as possible. But first, it’s worth understanding how HHVM runs your PHP scripts.
This article aims to walk through the installation process for getting WordPress running on HHVM (HipHop Virtual Machine).
Welcome to the inaugural post on the HipHop for PHP blog. In the coming days, weeks, months, and (dare I predict) years, we’ll be creating posts about the inner workings of HipHop, the practical implementation details of running it, and whatever else manages to fit on this site.
So sit back, add us to your RSS reader, and enjoy.