bsimmers
8733cdc4f3
Most of the SpillStacks we do are just to keep the in-memory VM stack clean in case a helper call throws an exception. Many of these exceptions are vanishingly rare, so let's stop making the fast path slower for them. This diff adds support for catch traces, which are just like normal exit traces with one major exception: they're never jumped to from translated code. If we're unwinding a TC frame and discover that the current rip has a catch trace registered, the unwinder will execute it before resuming unwinding. The unwinder parts were fairly straightfoward, then I ran into a bunch of issues with SetM. The SetElem instruction sometimes consumes a reference to one of its inputs, which is bad news for our optimizations. To make everything work again, I changed SetElem to throw an exception in cases where it would've previously decreffed the value input. This is a special exception that the new unwinding code recognizes. When one of these is caught, the catch trace executed for that TC frame will finish up the vector instruction and push the value provided by the exception on the stack. This allows us to optimize most traces under the assumption that SetM's output is the same as its input, letting the catch trace clean things up if the helper decides that's not the case and throws. There is one common case where SetM's output isn't the same as its input: setting an offset in a string base returns a new String. Luckily, we can detect most of these at compile time so SetElem returns a new StringData* when the base is known to be a string. If the base might be a string, SetElem will return nullptr if the base wasn't a string, and a StringData* if it was. We test the output in these cases and side exit if the return value of SetElem is non-null (I have yet to see this side exit happen outside of artificially created test cases). Once I got things working in the vector translator, I went through every other call to spillStack and exceptionBarrier, replacing them with catch traces as appropriate.
HipHop VM for PHP 
HipHop VM (HHVM) is a new open-source virtual machine designed for executing programs written in PHP. HHVM uses a just-in-time compilation approach to achieve superior performance while maintaining the flexibility that PHP developers are accustomed to. HipHop VM (and before it HPHPc) has realized > 5x increase in throughput for Facebook compared with Zend PHP 5.2.
HipHop is most commonly run as a standalone server, replacing both Apache and modphp.
Installing
You can install a prebuilt package or compile from source.
Running
You can run standalone programs just by passing them to hhvm: hhvm my_script.php.
HipHop bundles in a webserver. So if you want to run on port 80 in the current directory:
sudo hhvm -m server
For anything more complicated, you'll want to make a config.hdf and run sudo hhvm -m server -c config.hdf.
Contributing
We'd love to have your help in making HipHop better. If you run into problems, please open an issue, or better yet, fork us and send a pull request. Join us on #hhvm on freenode.
If you want to help but don't know where to start, try fixing some of the Zend tests that don't pass. You can run them with hphp/test/run. When they work, move them to zend/good and send a pull request.
Before changes can be accepted a Contributors Licensing Agreement (pdf - print, sign, scan, link) must be signed.
Licence
HipHop VM is licensed under the PHP and Zend licenses except as otherwise noted.