Symfony: Log outgoing responses with kernel events

One of the nicest features of Symfony2 is the Request/Response paradigm for processing a HTTP request and then sending a response back to a client. At a high level, Symfony’s HttpFoundation component provides an object oriented abstraction to easily deal with HTTP requests and generate responses to send back to a client. Assuming application code correctly uses HttpFoundation, it will only interact with request variables through the Request class, as opposed to $_REQUEST, and only send output using the Response class, as opposed to an “echo”. Because of this contract, the framework as a whole makes it easy to manipulate responses before they’re sent back to a client.

A typical use case that leverages this would be logging API responses before they’re sent back to a client. As much as an API might be RESTful, at some point it’s easier to debug things when you can see the responses that clients have been receiving. OK great so how do you do it? It’s actually pretty straightforward, just create a class to receive the “kernel.terminate” event and register it as a service with the appropriate tags:

And then create the class where you want to manipulate or log the requests:

And that’s about it!

Note: Per Andras’ comment below the event has been switched to “kernel.terminate”.

Symfony2 and Gearman: Parallel Processing and Background Processing

On a few of our projects we have a few different needs to either queue items to be processed in the background or we need a single request to be able to process something in parallel. Generally we use Gearman and the GearmanBundle.  Let me explain a few different situations where we’ve found it handy to have Gearman around.

Background Processing

Often we’ll need to do something which takes a bit more time to process such as sending out a couple thousand push notifications to resizing several images. For this example lets use sending push notifications. You could have a person sit around as each notification is sent out and hope the page doesn’t timeout, however after a certain number of notifications, not to mention a terrible user experience, this approach will fail. Enter Gearman. With Gearman you are able to basically queue the event that a user has triggered a bunch of notifications that need to be processed and sent.

What we’ve done above is sent to the Gearman server a job to be processed in the background which means we don’t have to wait for it to finish. At this point all we’ve done is queued a job on the Gearman server, Gearman itself doesn’t know how to run the actual job. For that we create a ‘worker’ which reads jobs and processes them:

The worker will consume the job and then process it as it sees fit. In this case we just loop over each user ID and send them a notification.

Parallel Processing

One one of our applications users can associate their account with multiple databases. From there we go through each database and create different reports. On some of the application screens we let users poll each of their databases and we aggregate the data and create a real time report. The problem with doing this synchronously is that you have to go to each database one by one, meaning if you have 10 databases and each one takes 1 seconds to get the data from, you have at least ten seconds the user is waiting around; this doesn’t go well when you have 20 databases and so on. Instead, we use Gearman to farm out the task of going to each database and pull the data. From there, we have the request process total up all the aggregated data and display it. Now instead of waiting 10 seconds for each database, we farm out the work to 10 workers, wait 1 second and then can do any final processing and show it to the user. In the example below for brevity we’ve just done the totaling in a controller.

What we’ve done here is created a job for each connection. This time we add them as tasks, which means we’ll wait until they’ve completed. On the worker side it is similar to except you return some data, ie `return json_encode(array(‘total’=>50000));` at the end of the the function.

What this allows us to do is to farm out the work in parallel to all the databases. Each worker runs queries on the database, computes some local data and passes it back. From there you can add it all together (if you want) and then display it to the user. With the job running in parallel the number of databases you can process is no longer limited on your request, but more on how many workers you have running in the background. The beauty with Gearman is that the workers don’t need to live on the same machine, so you could have a cluster of machines acting as ‘workers’ and be able to process more database connections in this scenario.

Anyways, Gearman has really made parallel processing and farming out work much easier. As the workers are also written in PHP, it is very easy to reuse code between the frontend and the workers. Often, we’ll start a new report without Gearman; getting logic/fixing bugs in a single request without the worker is easier. After we’re happy with how the code works, we’ll move the code we wrote into the worker and have it just return the final result.

Good luck! Feel free to drop us a line if you need any help.

Drupal 7 body content going blank? An obscure PCRE configuration setting may be the culprit.

Recently, one of our clients noticed that when they added additional text to the body field of a node with a bunch of existing content the changes would appear to save on the back-end edit screen but the body content of the page disappears on the front end without a trace and with no errors. At first, we thought it was a character or word count restriction that was placed on the body field or that a text-format filter/html combination was throwing things off. After checking a bunch of settings on the admin screen and testing different combinations of words, characters and text-format filters we came up empty handed.

Turns out it was an obscure setting within sites/default/settings.php. If you open this file and search for ‘pcre.backtrack_limit’ you’ll find a surprisingly accurate description of the problem at hand:

/**
* If you encounter a situation where users post a large amount of text, and
* the result is stripped out upon viewing but can still be edited, Drupal’s
* output filter may not have sufficient memory to process it. If you
* experience this issue, you may wish to uncomment the following two lines
* and increase the limits of these variables. For more information, see
* http://php.net/manual/en/pcre.configuration.php.
*/

# ini_set(‘pcre.backtrack_limit’, 200000);
# ini_set(‘pcre.recursion_limit’, 200000);

So once you comment these out and increase the limits you’ll find that the body content reappears on the front end.
Since everyone’s server setup is different, you’ll have to experiment with what values work best for you. Here’s a link to the php.net manual for this configuration setting: http://php.net/manual/en/pcre.configuration.php.

Hope this saves you some time and frustration!

PHP Town Hall: Episode #18

As a follow up to How will HHVM influence PHP?, Phil Sturgeon had shared a link to PHP Townhall Episode #18 but unfortunately there was no transcript available. We decided to get it transcribed for the community and the text is below along with the video on the left.

Phil Sturgeon: Hello everybody. Welcome to episode 18 of PHP Townhall. We’ve all just spent the last hour fucking around with Google Plus because it is a ludicrous system. If you’ve been trying to watch this live, we really do apologize. We done a few of them and it seemed to work OK, but this time it was not playing ball. This is our 3rd different video, different try. It’s taken a full on hour, but the good news is we have joined with 2 awesome guests. That should make up for the problems. We have Sara Goleman of HHVM and Facebook fame. We have Joe Watkins, the legend behind P Threads, and PHP Debugger. Hello guys, how are you doing?

Joe Watkins: Fine.

Sara Goleman: Frustrated, but fortunately I’ve had to calm down after being furious at Google. I’m already past the curve.

Phil Sturgeon: That was quite unlike anything I’ve ever had to go through with Google Plus. I do apologize once again. Before we start off, actually Sara, can you explain what’s on your wall back there?

Sara Goleman: Back on my wall here. For those of you familiar with the Grumpy Cat meme, this is Grumpy cat, or at least my attempt to redraw him. I did OK with that. This was actually originally a autograph I did for Grumpy Programmer Chris Harches in my exciting embedding [inaudible 00:01:24] book. I [inaudible 00:01:26] really teach the extension once, I hated it. It was awful. That’s what it’s supposed to be.

Phil Sturgeon: Yeah, Joe, you’ve done a [inaudible 00:01:36] bit haven’t you?

Joe Watkins: What?

Phil Sturgeon: Writing extensions for PHP. How much fun was it?

Joe Watkins: It’s much fun, yeah. Yeah it’s good.

Phil Sturgeon: OK, we’ll get back to that a little bit later on. What else have you got on your wall there?

Sara Goleman: I’ve got the infamous PHP double claw hammer. Maybe familiar with the shirt that you’re producing.

Phil Sturgeon: That’s pretty good detail. Pretty cool drawing [00:02:00]. Yeah.

Sara Goleman: I felt I needed some kind of backdrop here. All the code bits that were on there were on there were less interesting.

Phil Sturgeon: Definitely. I’ve got some random stuff right here. I’ve got a painting that one of my friends did which is of the American flag. I think I’m going to be called a traitor now.

Sara Goleman: Oh is that what that is?

Phil Sturgeon: Yeah. It’s a …

Sara Goleman: I thought it was like bridge works or something.

Phil Sturgeon: It’s like the Nazi thing. Yeah, that’s good fun. Joe, you are losing this game of having random stuff in the screen. You didn’t plan ahead.

Joe Watkins: I didn’t. I didn’t know it was [inaudible 00:02:32].

Phil Sturgeon: Speaking of planning ahead, I probably don’t [inaudible 00:02:35] at that. Excellent, it’s good to have you guys here. You guys have been working on some really awesome stuff recently. One of the first things you should talk about is PHP Debugger. The first question Joe, what is PHP Debugger and who is it for?

Joe Watkins: It’s for the same kind of people that use Xdebug now, but Xdebug goes about things differently. Instead of Xdebug changes the environment, it even changes the instructions you’re executing in order to provide what it does. Rather than doing that which is quite intrusive, it aims to be the environment rather than change the environment. It’s much easier to provide steps for debugging and proof [inaudible 00:03:37] stuff like that. You don’t have to change everything around it. It’s for the same sort of people, but just in a different kind of way. I’m quite used to debugging with a proper debugger because that’s how you debug codes.

Phil Sturgeon: That sounds like a pretty logical way of looking at it [00:04:00]. I suppose for anyone not familiar with Xdebug, Xdebug is an extension for PHP, which you can just like enable in your environment and then it kind of latches on to various different points in the execution of whatever SAPI you’re using. If you’re using it with mock PHP in Apache or you’re using it over the command [inaudible 00:04:20]. Xdebug hooks into that SAPI. Do you say SAPI or S-A-P-I? Whatever.

Sara Goleman: I say SAPI.

Phil Sturgeon: SAPI? OK cool. I usually just type this stuff in ISE when I’m arguing with people. I don’t actually say it out loud. Yeah, it kind of hooks into the SAPI and does stuff which is a bit of a not necessarily efficient way of doing things. It’s not bad, it’s just a different way of doing things. With PHP debugger, it’s pretty much a specifically designed SAPI purely for debugging instead of being your normal SAPI with hooked on latches from an extension. I think I might have done a really bad job on explaining that too.

Joe Watkins: That’s the place [inaudible 00:05:07]. That’s basically it.

Phil Sturgeon: That’s cool. What made you want to build that? What do you feel was lacking with tools that were available?

Joe Watkins: I don’t really like Xdebug because I don’t really do a lot of debugging. It’s good at that. Xd runs really good at that. It’s got good IT support as well which PHP doesn’t have yet. It probably will do, but it doesn’t yet. I don’t do remote debugging. I do work mostly on the command drive. The things that JDB does, I consider that a debugger. I just went with that. It was only meant to be like a weekend thing and then it worked out quite nicely. We decided it was good enough to [00:06:00] finish them and keep … There’s nothing wrong with Xdebug. It’s very good. It’s very powerful. It’s got lots of things that it does, but you need to pay for that and that your code is not the same anymore. In a way, when you debug with Xdebug, you’re kind of debugging Xdebugger. You profile in Xdebug because it changes everything so much.

Phil Sturgeon: Right.

Joe Watkins: I just didn’t want to do that in order to get the same features, so that was the idea.

Sara Goleman: Surely PHPDBG has to do some amount of reaching into the engine internals. If you’re setting a break point or something like that.

Joe Watkins: It doesn’t change the operating flow, it actually re-increments-

Sara Goleman: Oh.

Joe Watkins: An execute function.

Sara Goleman: OK.

Joe Watkins: It is actually that function so it just gets control over that switch. It goes in and out of DM-

Sara Goleman: Right.

Joe Watkins: It doesn’t have to touch any operates.

Phil Sturgeon: That sounds pretty cool. My next question was going to be what is the most equivalent [inaudible 00:07:14] all in other languages. Is there something in Ruby or Python that you modeled this around? You said J something?

Joe Watkins: Oh, JDB. That’s the CD that I’ve got. [inaudible 00:07:26] has got a debugger though.

Sara Goleman: Mm-hmm (Affirmative).

Joe Watkins: Which is pretty much the same.

Phil Sturgeon: Oh you just copied Sara.

Joe Watkins: I actually genuinely didn’t. We wrote it and then we noticed it was kind of the same so we did make some of it the same, but we came up with the idea independently. Then someone said to us, oh have you seen this? Then that was when I saw the bug post saying that JGM had one.

Sara Goleman: You probably modeled it heavily on JDB which is like the standard for debuggers.

Joe Watkins: Yeah it’s the standard debug [00:08:00] [crosstalk 00:08:01].

Sara Goleman: We did the same thing.

Phil Sturgeon: I was going to say this sounds a lot like when both Pixar and some other company, Disney or somebody, one of them made A Bug’s Life and the other one made Ants completely independently and they came out in the same month and they’re like son of a bitch. It’s the same movie.

Sara Goleman: I’m sure there was an executive producer who knew about the other one and just didn’t want to admit it. They always do that in pairs like that.

Phil Sturgeon: Sneaky sneaky. Yeah, you made that and it’s a bit of a weekend project. I guess it probably took a little bit longer after you first started hacking around with it. It’s on knot 3 know now, so it’s getting pretty close. How far off do you think it’s [crosstalk 00:08:40].

Joe Watkins: It’s stable enough. It’s got all the features we wanted it to have. The only things that are being planned now are pretty geeky. Watch points, which [inaudible 00:08:57]. That is not something I’m writing. Someone else is writing that for it. It’s usable now. It does basically the things that you use from JDB, it does.

Sara Goleman: Yeah.

Joe Watkins: Anything else is just frivolous really.

Phil Sturgeon: That’s cool. I spoke to you before about could it provide a basic web server. Is it going to do that sort of thing. You said it could in the future help integrate with a web server because one of the things I really like about Ruby is, I can’t remember how it actually works, but a Ruby fan boy showed me a while ago. You can put in break points in your file in a certain way and if you’re using the built in rail server then it just stops execution at that exact point and then you can just start dumping out variables and messing around with things. That is amazingly powerful as I’m sure you know. I realize that the debugger wouldn’t be a PHP server itself, but would it be able to integrate with the built in development server to offer that sort of functionality or is that not even vaguely on the road [00:10:00] map?

Joe Watkins: The built in development server is not like a full blown server with a Epi and things. It’s like something that they are not sure on, but it was never designed to be ostensible and work with everything else. It was just designed to just give you a development server.

Phil Sturgeon: Right.

Joe Watkins: I think it could happen, but it couldn’t happen in its current form. Probably it would just be better just to write a server around it rather than try to reuse all the work on the development once s that it could do that, but it was never really designed for that. It [inaudible 00:10:42] do that. It can do a kind of remote debugging now. Not like Xdebug does it. It just basically sends input and output over the network with it’s [inaudible 00:10:56] sort of inetd style. That means you can connect to it from remote machines. Like I said, it’s full of cons though really. You can emulate a web request quite easily because a web request is just an environment with some super global set and some other variable set. It’s not like it’s impossible to lock anyway. You’ve even got more control over it if you’re locking it because for obvious reasons you’ve got more control over it. There’s not that much incentive to put all the hard work into developing the built in server. That would just complicate the built in server. It works fine.

Phil Sturgeon: Yeah, fair enough. The one argument against that is Rails has it. We want it.

Joe Watkins: Yeah.

Phil Sturgeon: We want the shiny thing. No, that’s fair.

Joe Watkins: Give me, give me.

Phil Sturgeon: Well [00:12:00] actually a random quick question. Which part of the UK are you from?

Joe Watkins: Kent.

Phil Sturgeon: OK, I was trying to work the accent out. Never mind. That’s just something for me. The rest of the community probably aren’t too bothered about that.

Sara Goleman: I was assuming he was from somewhere further North.

Phil Sturgeon: Yeah, it’s a bit of an interesting accent. I wouldn’t have said Kent. There were bits of it that made you sound like the Southeast, but who knows. My accent has apparently gone Americanized and people say I say different words weird and I don’t understand what that means, but never mind. Do you have anything else you want to talk about with PHP Debugger or should we get onto HHVM?

Joe Watkins: Let’s get onto HHVM, yeah.

Phil Sturgeon: Yeah, cool. OK. Yeah, keep on like jump into my questions. This should be like a 3-way chat and not just me asking stuff. I’ve got a couple questions to ask you Sara. You’re involved obviously with HHVM. I think you said the other day like you are HHVM. You’re pretty much leading that project?

Sara Goleman: I didn’t want to say that in a sense of oh I am HHVM, just more of like I have my loyalties to PHP, and I have my loyalties to HHVM and they’re not at odds. We’re all trying to make an awesome language. That’s all I meant by that. I didn’t mean to say that I am the project. There’s actually a whole bunch of us on it. There’s me and a couple of other people doing the open source side of things and then there’s a group of people doing performance stuff and there’s a group of people doing extensions to the language. New stuff like Hack that I’m not talking about.

Phil Sturgeon: Nice. Well, OK. That’s a shame you’re not drinking because we could try and pry it out of you. If you could just do a really quick 30 second introduction to what is HHVM for somebody that’s been living under a stone and doesn’t know what it is.

Sara Goleman: Well, it would be fair if you didn’t know what HHVM was because we really have only started pushing and talking about it really publicly in the last year or so. HHVM [00:14:00] is a complete re-implementation of the PHP language in runtime. Everything is rebuilt from scratch. The idea was to make a execution engine that could at least match code that had been written in CRC++ or possibly even exceeded. Basically get rid of the performance bottleneck pieces that are in PHP. Obviously you still have blocking socket and network requests and things like that but anything that is the language should be pulled out of that delay stack. What we’ve done is we’ve built something that goes through a few steps. The first step looks a lot like PHP. We take the source code that you write, turn that into byte codes and we have a virtual machine that will run those byte codes one through the next. That’s just like how PHP works. Then on the end of that, we have a jit that takes all those machine codes, figures out all the different ways they can branch and fit together and we create a native x86 code out of that. The code that actually ends up running in production is as fast as as if you’ve written in C and you have GCC compiling that into machine code because it’s going through basically the same set of steps.

Phil Sturgeon: Sweet, so it goes fast.

Sara Goleman: It goes fast. It makes PHP fast is the TLDR version of that.

Phil Sturgeon: Excellent. There are some people that are confused about exactly where HHVM fits next to actual PHP.

Sara Goleman: Right.

Phil Sturgeon: That would be a fair confusion to have mostly because PHP is essentially 2 things. In fact, most languages are known as 2 things. There’s usually the language in the syntax and then the implementation of that language. In Python by default, usually when people refer to Python, they’re talking about the Python language which is a specification and C Python which I think is the most common one. There’s also R Python and Pi Py [00:16:00] and all these other implementations or different engines for the same language or similar language.

Sara Goleman: Ruby does that as well.

Phil Sturgeon: Right, yeah. They’ve got [inaudible 00:16:08] Ruby and a bunch of other things. It’s pretty common and PHP doesn’t really have this. We have the same idea. PHP is both the language and the syntax and all the shit you that you see and then this Zend engine which I think replaced some other earlier on engine I don’t know that far back. This Zend engine is like the default, what do you call it? Like the reference implementation. It is the [crosstalk 00:16:31].

Sara Goleman: I wouldn’t even site the end engine as separate from the runtime because they’re so tightly coupled that the main page for your runtime, the stuff that gives you the functions like [stur-ree place 00:16:46] and things like that is almost a 1 to 1 mapping to the Zend engine. I wouldn’t even separate those anymore. There are a few other implementations out there. Things like Falinger. There’s … What was the name of the other one … It had a 7 in the name somewhere. It was a really weird name, but there are a couple of re-implementations of [inaudible 00:17:07].

Phil Sturgeon: Can you send me some links to those so I can put them in the show next, if you remember them.

Sara Goleman: I will try to dig them out, yes.

Phil Sturgeon: Cool. Yeah, Joe, what were you going to say? You were about to pop in there with something. Saying that like the functions [inaudible 00:17:23].

Joe Watkins: I was just saying there is a myth that Zend [inaudible 00:17:27] PHP, etcetera and everyone talks about it, but they’re not.

Sara Goleman: No.

Joe Watkins: They’re not. They’re the same thing.

Sara Goleman: At various points, we’ve tried to make a nice clean separation layer, but every time somebody spends a lot of effort to making that separation glare, it ends up degrading and going away. If you look through PHP SourceTree you’ll see references to things called pvals. Pvals were supposed to be the PHP agnostic version of a zedval which is what represents variables inside PHP. See that? I used your terminology [00:18:00] for the last letter in the alphabet.

Phil Sturgeon: Excellent. Yeah, I think the separation of PHP and Zend is just purely imagined. What it really could be. All of the functions, most of the syntax are just how Zend engine works. Realistically at the moment I suppose PHP just is Zend engine, but something I saw in internals fairly recently which I’m sure is a recycled conversation which has come up many times in the past is that people would like to bring HHVM into it like as a colonel.

Sara Goleman: I want that discussion.

Phil Sturgeon: Well yeah, whether that specific discussion was crazy or not, what ended up being talked about was it would be great if PHP could be defined as a spec and then the engines would implement that spec and that’s a crazy in a perfect world, we can be like Python and we can write a [inaudible 00:18:50] for the spec of PHP syntax. It would be insanely hard. I have no idea who would run it, but theoretically do you guys think that would be a good thing maybe for PHP 6?

Sara Goleman: Well the first thing I want to answer is about the question and the way the question was phrased specifically says something about the person who posted it. They said is it time for HHVM to be merged into PHP? That question by itself is completely wrong because they’re 2 completely separate implementations and I think part of that perception issue that you were talking about earlier, what is HHVM? Is it something that you add into PHP like Zend optimizer or APC? No, it’s actually a completely different thing and merging it isn’t even the right question to ask. If the right question to ask is is it time for HHVM to become PHP 6, or more likely 7 because I don’t think there will be a 6. That’s a whole different question to ask. That requires a lot of work yet.

To the question you asked of [00:20:00] does it make sense to have a formal PHP spec for the language that different implementations can follow? Absolutely. We’ve keep coming back to what’s PHP doing? Are we not matching them correctly? Let’s make sure our syntaxes are alike and we have something alike. A spec for that purpose, but it’s a necessarily fuzzy thing because the Zend engine keeps moving. I think it would be really valuable to the PHP project and to other implementations to have a formal spec to follow, but like you say that’s a lot of work and somebody’s going to have to do that work and keep it up to date.

Phil Sturgeon: Yeah. Joe, do you have anything to throw in on that?

Joe Watkins: Yeah, the other thing to say is that part of the strength of PHP is the enormous amount of extensions.

Sara Goleman: Mm-hmm (Affirmative).

Joe Watkins: Putting a spec out there might allow others to implement the language, but it won’t allow them to put in all the effort to implement all the extensions that there are. That’s the only other thing to say about that. It’s a massive task to re-implement all of what you get when you download PHP. It’s not just a spec.

Phil Sturgeon: Right.

Joe Watkins: [inaudible 00:21:17].

Sara Goleman: If you compare it to Python, Python is really easy to write another implementation of because it’s just the language and then you import the modules which tend to be written in Python. PHP is not that kind of a beast.

Phil Sturgeon: Right.

Sara Goleman: PHP is this massive bloated mass and that’s my [inaudible 00:21:38].

Phil Sturgeon: Yeah. With Python you can implement the modules which is nice and easy obviously, but they’ve had the same problems that we have if PHP was to become a spec. With C Python, you can include any modules that are written as … There’s a lot of C extensions just like we have [00:22:00] and you can include those. If you’re using Jython or IronPython then tough. You can’t use them. That would be a bit of pain for us obviously.

Sara Goleman: Well, I’ll tell you, we’ve actually run into that thing because HHVM being a re-implementation means we have to re-implement all of the runtime. Every extension, everything like that. One of the guys on my team Paul, has written something he calls X Zend Rapper. The idea is to be something source compatible so that you can take any PHP extension, drop it into our SourceTree, and it will just not only compile, but actually you can work correctly. Every function call will map all the things correctly. They’ll become zvals and the return values will map back into variants. In practice, it always seems to work for about 30% of extensions. That’s more than 0.

Phil Sturgeon: That’s playing with a kick in the teeth isn’t it?

Sara Goleman: Yeah.

Phil Sturgeon: That sounds pretty cool. Yeah, something when we were talking about HHVM over Twitter, I think I made some generalization about the way … Oh you can see my girlfriend wandering around in the back. Say hello Kim.

Sara Goleman: Hi Phil’s girlfriend.

Phil Sturgeon: There she goes. She’s gone. Someone was suggesting that HHVM could well be the new version 6 and I was saying without a specification it becomes a little bit tricky to do because quite often you’ll see the people from the PHP group will want to work on a certain feature and they want it to work a certain way. Other times there will be a feature that you guys want some of the features return types of functions and methods right? You wanted that so you guys worked on that feature. The PHP internals group pretty much said no we don’t want that or we can’t do that now, or whatever. While they were still working on how that would actually work or talking about it, you guys implemented that.

Sara Goleman: Mm-hmm (Affirmative).

Phil Sturgeon: What I ended up saying I think probably sounded more exaggerated than I meant, but [00:24:00] I was pretty much saying with the PHP group they obviously have a BC as a massive [inaudible 00:24:05]. Backwards compatibility is the utmost most important thing in most decisions that they make which is great, but with HHVM it still hasn’t got a version out so you guys can kind of do what you like. That was based around my perceptions of HHVM early on when there were bigger changes being thrown around and now it seems like you brought it back a little bit and brought it closer in line with the current implementation of PHP. Is that about accurate in the path of HHVM or am I just talking shit?

Sara Goleman: No, you’re completely right. We share some of PHP’s backwards compatibility concerns. We want as much PHP code that’s out there in the wild to run on us as possible. We try to avoid breaking anything by saying well, we’re just not going to do that. [inaudible 00:24:57] promotion is something that PHP does, we don’t do that. Your integers will just wrap around once you reach max. Those are few and far between, but at the same time, we have these set of features that we want to include in the language so we’re adding them in. If and when PHP actually gets around to adding something similar, the actual implementation may or may not be the same thing. Generators are a good example of that.

We implemented generators a few years ago, and then Nikita came along and said hey I think we should put generators into PHP. Here’s my proposal for what that looks like. That initial proposal actually ended up looking just different enough to make trying to write a generator for either implementation difficult. I asked him very nicely can we just change this one little thing so that they’re compatible and he was amenable to that. That worked out well enough there, but there can easily be situations where that doesn’t work out. Return type tints are probably a good example of of [00:26:00] that. We’ve got them at the end of the declaration. You do colon blah, which I believe is the way Pascal does it and a few other languages.

There were a couple of proposals up that put it between the function key word and the actual function name in the declaration. Some with alligator brackets, some with parenthesis. If that were to happen, we’d have a problem. The way that we’re trying to avoid having that be a problem is we actually have 2 operating modes. We’ve got the PHP mode, which you start your files with less than question mark PHP. That is really really close to normal PHP syntax. I think there’s still a couple of minor differences but it’s really close. They’ve really got the pack mode which is less than, question make, HH. This is where we’ve got all the fancy new features that are specific to HHVM like all the texture type hinting and things like that.

The idea is if you’ve got some piece of code that is written for PHP and you want to run it on HHVM, well it’s already got the PHP open tag on the top so it’s going to run in PHP mode and no problem. If you want to write code that takes advantage of all these extra features you throw the HH on the top and OK now it only runs under HH, but it runs. Trying to [inaudible 00:27:26] a little bit.

Phil Sturgeon: That sounds like a pretty good way of doing it. If you have this new file type that can handle new stuff in other ways it will run pretty much exactly the same. One question I wanted to ask was which version of PHP would you say HHVM is most like because there was a while when it was only 5-2, 5-3 somewhere around then and most of the new functionality haven’t been implemented. That’s probably like a year ago now or something. I don’t remember. What is it currently most like? Is it 5.5ish?

Sara Goleman: Syntax wise, if you want to take us to a version, I would peg us to 5-4 [00:28:00] although we do have some 5.5 things.

Phil Sturgeon: Like generators.

Sara Goleman: Yeah. The one 5.5 thing we’re missing right now is the final keyword. We don’t handle those yet, but we do plan to handle them soon. Then you can call our syntax 5.5. The fuzzy part of that question is again, PHP and Zend really aren’t separate things. The runtime is tied to the syntax. Our runtime support is a bit all over the map depending on what extension you’re looking at. We’ve got a whole bunch of standard implemented, the [inaudible 00:28:35] extensions are generally pretty close. Intel is missing about half of it’s functionality for example. I’ve been working hard on that, but there’s a lot to implement. It’s a huge extension.

Phil Sturgeon: Sorry, which extension is that?

Sara Goleman: The Intel extension. All the ICU stuff.

Phil Sturgeon: Oh OK. Yeah.

Sara Goleman: Like deep formatter, number formatter, blah blah blah blah.

Phil Sturgeon: Oh dear and like all the different international stuff.

Sara Goleman: They all interact and plug into together and the date time stuff fits into Intel date time back and forth. It makes it a really delicate beast to deal with.

Phil Sturgeon: That is tricky. There’s a couple questions actually that I meant to ask and skipped past. What was I going to talk about? Shit, that faded fast. God damn. Yeah, you’re talking about PHP 6 and is that going to happen. Joe, what do you reckon is going on there because I know that PHP 6 has become this scad. Everyone just doesn’t want to touch it. I realize it was meant to have unicode support and then they couldn’t quite work that feature out so everyone bailed on PHP 6 and [crosstalk 00:29:47].

Joe Watkins: It’s not that they couldn’t work it out. It could be worked out, but you didn’t really want it.

Phil Sturgeon: Yeah. Well, I heard people were basically against the idea of having UTF8 support because [00:30:00] it wouldn’t have covered all of the use cases. Then the old alternative was UTF16 which would have been slow and therefore something we don’t have it.

Joe Watkins: It would have been terrible. Most people don’t actually need what was being done.

Phil Sturgeon: Mm-hmm (Affirmative).

Joe Watkins: It just wasn’t necessary.

Phil Sturgeon: Is that a case of people over engineering the situation? If UTF8 gets a lot of people by and covers most use cases or at least a lot of more use cases than having no UTF whatsoever. Wouldn’t it be good enough to add UTF8 and then maybe have some support for other UTF8 levels in the future than just have nothing and say fuck it, it’s hard, let’s not bother.

Sara Goleman: Well what would you call adding UTF 8 because everything string in PHP is just a string of binary data and it can be UTF8 if that’s what you add. What do we call adding UTF8 support? Is that just every string that is set is just automatically validated to be valid UTF8 sequences? Or what about the data that you don’t want to be?

Phil Sturgeon: Yeah, that’s understandable. I don’t need to tell you guys this stuff. In Python they have a little U at the start and then that demarks the string as some other type.

Sara Goleman: Yeah.

Phil Sturgeon: I’m sure you guys considered that stuff, but what was the reasoning against going against something like that? Would it just not fit in with the PHP way.

Sara Goleman: Well, I think the vote against just making unicode strings be UTF8 validated basically really didn’t buy much of anything. There are ways to validate the term that is correct. When dealing with data that comes from the server like all the query strings stuff, you can’t necessarily apply UTF8 validation to that at the front because you don’t know that you’ve got UTF8 coming in. The ways of guessing encodings are not reliable [00:32:00]. Even in the best of cases.

Phil Sturgeon: Right.

Sara Goleman: Those wind up being binary strings until you actually explicitly said OK here it is as a unicode string. It just doesn’t buy you much of anything. If we went to a UTF16 representation underneath the covers, that mght have bought us a little bit more because we could build some better functionality in terms of [ster-line 00:32:24] gets properly overloaded to check the UTF8 streamline. That deals poorly with anything outside of the basic multi lingual plane and it also doubles your memory requirements for most strings. There’s nothing that’s really a good win anywhere.

Joe Watkins: Nowhere. You [inaudible 00:32:47].

Sara Goleman: Well, OK, so regardless if UTF8 was just not helpful at all or not doable, whatever it was. Regardless of that, that was the main thing that killed off PHP6. For the longest time it looked like we weren’t going to have a PHP6 because of that because somebody at some point said unicode string support is going to go into PHP6. It seems like we’ve now blocked ourselves from ever really being able to have a PHP6. Were we really going to go to 7? Is that a consensus?

Joe Watkins: What kind of consensus?

Phil Sturgeon: When we were on 5.3 we had loads of space. We had 5.4, 5.5, but now we’re on 5.6. We’re running out of minor levels to get there.

Sara Goleman: well, no no the version numbers aren’t going to be stopped at 9. You can have 5-

Phil Sturgeon: You can have 10, 11, I know, but there’s a certain expectation that at some point we’re going to have to get out of the 5 level.

Sara Goleman: Well, getting out of the 5 level, whatever we go to be it 6 or 7 or whatever, means having some significant change in the language. 4 to 5 was a significant change in the language because now objects are no longer cloned by default. 3 to 4 was a big change in language because [00:34:00] the entire semantics of the engine were changed and that change had downstream effects all over the place especially with extensions. 3 extensions were not compiled on PHP4 for example. What would justify, this is a whole new PHP. Nothing that has gone into 5.4 or 5.5 or 5.6 or even 5.7 is looking like that. They’re all incremental things. Extra runtime stuff, maybe a few syntax changes like adding [fine-lee 00:34:36] and things like that but they’re not massive.

Phil Sturgeon: That makes sense. I feel like I’ve seen a few … I’m sorry Joe, did you have something to say on that? Or were just saying Mm-hmm (Affirmative).

Joe Watkins: Nod. Yeah, just agreeing really. You need something big to call it a new version and one [inaudible 00:34:53] who mentioned stuff and if you get the reply of let’s leave it to PHP 6 that basically means they don’t want it.

Phil Sturgeon: Yeah. That’s exactly why I was asking this line of questioning because I started paying attention to PHP internals a bit more recently and I started getting involved in a couple of conversations. I feel like I helped out a tiny bit with the PHP debugger when people were just getting confused and I just left a reply explaining what it was for and things and that kind of helped so yay for that. I’ve been paying a little bit more attention to what’s been happening with internals and I’ve seen a lot of discussions that seem to go that way. People discuss the [inaudible 00:35:32] and the pros and cons and the eventually someone says oh no we should probably put that in PHP 6 which seems like a really polite way of saying get fucked. They just want to dump it off to PHP 6.

Joe Watkins: It kind of is, but at the same time, what [inaudible 00:35:46] piled up in the corner. We keep saying oh yeah whatever in PHP 6. Well it’s enough for them to pile it up in the corner then we would have enough changes that amounted up to a significant change. Like the engine perceptions and things like that. [00:36:00] there are big backwards compatibility breaks that you can’t possibly put in now [crosstalk 00:36:06] it will have to come to something.

Phil Sturgeon: This again was something I was about to ask. The most recent and prominent example I have of someone saying oh 6 was the engine exception stuff when Nicky was trying to make it so that [inaudible 00:36:21] get handled as exceptions. That would be a great start. Then he was talking about maybe making more and more things start to throw exceptions instead of errors in some cases. That was something that seemed to be put off to 6. I can’t remember an example of the other RFC’s or suggestions that were being punted back. The main thing for me is as long as someone is keeping track of all of these things that get shut down with oh fuck it in 6. If people just keep replying with that and then it gets dumped and then the conversation goes dead then if someone got a little to do list of what 6 is going to be and if so what’s the criteria.

Joe Watkins: The conversation often moves off official paths, but it never really dies. You put time and effort into an RFC, don’t forget about it. You keep coming back over and over again, but the [inaudible 00:37:12] on property access is [inaudible 00:37:12]. They won’t really handle it and it keeps coming back and it will until it gets in.

Sara Goleman: That’s a nice heading about having the RFC’s on wiki.php.net as we do have this record of things that we’ve talked about. We’ve got a spot where you can say not yet as opposed to no.

Phil Sturgeon: It’s never completely a fuck off, it’s just a maybe get lost for now.

Sara Goleman: Well what goes into the language is up to all of us. This language doesn’t have a BBFL. Getting something into language sometimes just means having the right timing go to to make that happen.

Phil Sturgeon: Sorry, my girlfriend is trying the best she can to distract me. We are running a bit late thanks to my kerfluffle with the Google Plus stuff and she’s [00:38:00] just showing me things on the iPad. Anyway, we’ve still got a little bit left. Yeah, I forgot what I was talking about.

Sara Goleman: Wow, she did a good job.

Phil Sturgeon: She has completely fucked me off my track.

Sara Goleman: We were talking about doing things to PHP 6 and how we can revisit them.

Phil Sturgeon: OK, are there any things you guys can think of recently that have punted back to 6 that you would love to see happen that you feel like aren’t happening at the moment?

Sara Goleman: Honestly, all the things I would like to see happen have gotten through the RFC process to actually to become a thing. Actually since we now have a splat and veriatics both approved in going in.

Phil Sturgeon: Yeah, those are 2 of my favorites from 5.6. I was pretty excited about them.

Sara Goleman: Yeah. I can’t wait to see those.

Phil Sturgeon: Which means that chances of named parameters are looking surprisingly strong or am I being overly optimistic. [crosstalk 00:38:54].

Joe Watkins: With our engine exceptions.

Phil Sturgeon: Sorry?

Joe Watkins: The key is [inaudible 00:38:59] finish that without engine exceptions.

Phil Sturgeon: Oh really? Why [inaudible 00:39:03].

Joe Watkins: Because he just doesn’t like the implementation without them.

Phil Sturgeon: OK.

Sara Goleman: Well perhaps those 2 together-

Joe Watkins: Yeah.

Sara Goleman: Could be that justification.

Phil Sturgeon: That makes sense to me because I have wondered why [inaudible 00:39:15] have seemed to go completely cold. There was a lot of discussion around it and [inaudible 00:39:22] in general and there was a lot of things happening on internals. Then veriatics went in and then like a month or 2 or 3 later the [inaudible 00:39:31] packing that got voted in recently I think.

Sara Goleman: Mm-hmm (Affirmative). Yeah.

Phil Sturgeon: Or a month ago. I remember threatening to break [inaudible 00:39:38] kneecaps over the Christmas period for that one.

Sara Goleman: No, he’s making it past Christmas.

Phil Sturgeon: Yeah.

Sara Goleman: [inaudible 00:39:44].

Phil Sturgeon: Oh yeah, no it was the Christmas party so yeah before that. I was threatening people’s kneecaps at the Christmas part. Whatever. That seemed like a really good RFC to go in and that did very well. I was actually impressed with the way that the conversation for that [00:40:00] largely kept completely on track. There have been a few times where the conversation got truly what the fuck a few times. It always seemed to be fairly on point and there wasn’t this way of counter trolling that often happens and Nicky did a very good job of just keeping it on track. That went in and that was great. Then [inaudible 00:40:19] just seemed to have not done anything. If he’s waiting for engine exceptions, then that would explain where it is.

Sara Goleman: Yeah.

Phil Sturgeon: Would you say engine exceptions is likely to have to be a version 6 or is that looking to be 5.6?

Sara Goleman: I think that has to be a next major version personally because that’s going to change the way a lot of people’s code works and responds to bad events. Particular in the error case because there’s an assumption that an E error is non recoverable and making an exception makes it something that you expect to be able to recover from. I think it’s going to take a little bit more work than that.

Phil Sturgeon: Yeah. I was talking to a few people, I was chatting away with Anthony over beer, so it might not have been hugely accurate. He was explaining that, and it’s the same stuff that Nicky’s been saying, that a lot of the things that are currently defined as fatal errors in PHP shouldn’t necessarily be fatal errors right?

Sara Goleman: Correct.

Phil Sturgeon: There’s a couple of things that I think [inaudible 00:41:26] was explaining that with a fatal error, the entire point of a fatal error is that a fatal error is completely unrecoverable. The system is in a mess. Recovering from it would be too difficult and then everyone would just get confused. By turning every single fatal error into a oh no it’s fine carry on, do what you like would be really just bad for everyone. I think what Nicky and Anthony were both talking about was trying to make some of those things not actually be fatal or not as fatal as they appear. Things like this method isn’t available, don’t cry about it, just carry on e[00:42:00] because we can probably just not worry about it. Then there’s things like you run out of memory, like fatal.

Sara Goleman: That’s pretty fucking fatal.

Phil Sturgeon: Yeah there’s nothing you can do about that apart from like sorry mate you’re screwed. I did actually have a drunken suggestion to Anthony that he didn’t hate and that I hadn’t thought about was there could be an instance where you set up essentially like memory transactions. Bear with me a second on this. The instances where you run out of memory are usually you’ve tried to read a 1GB string into memory and you don’t have enough and those are recoverable right? Because you tried to read this 1GB string, it failed, oh look you’ve still got all of your memory left. Great.

The ones that really cause you to run out of memory is when it’s like 500KB. 500, 500, 500, 500, and then you get to this point where half way through you run out and you’ve still only got 500 left and that’s not even enough to do anything useful with. It just cracks the bed because there’s nothing you can do because you have all this stuff. I came up with the suggestion of somehow kind of like database transactions. You could define a point. Just run a function or something that says I’m going to start doing something in a big old fucking loop and if anything fails it should pretty much get back to the state of where it’s here.

Then you run through this loop if it completely fails, it runs out of memory it goes get rid of all of that, anything that was registered after this event was started get rid of it. Then you carry on. He said that that might be a good idea, but he might have been pissed. Does that sound crazy?

Sara Goleman: That’s something we could totally do if PHP extensions were written in C++ it would be really easy to do that. It turns out they’re not. They’re mostly written in C. One of the things that extensions offers right now rely on is if I call [E-Malick 00:43:48] it will either return with a valid pointer or it won’t return at all because it’s thrown a E error and fallen out. Changing that semantic [00:44:00] would just be brutal to any existing extensions and it would take a huge refactor of the main SourceTree to make it work right.

Joe Watkins: The [inaudible 00:44:13] because if [E-malick 00:44:15] returned null all the code is referencing something it knows is there because [E-Malick 00:44:20] always returns.

Sara Goleman: Right.

Joe Watkins: It would actually [inaudible 00:44:22] it would be fatal. It couldn’t really do that.

Sara Goleman: That would be bad.

Phil Sturgeon: OK, so I solved that plan. That’s not a route you could take.

Sara Goleman: Well it is a route you could potentially take, but it is fraught with such perils and pain and there’s not enough beer in the world.

Phil Sturgeon: OK, that makes sense. Until I learn C enough to be actually good enough to do it then no one’s going to bother.

Joe Watkins: The other thing you can do is raise your memory limit. If you’re running out of memory then you could just raise it.

Phil Sturgeon: Yeah. That makes sense. That sub question was just something I remembered whilst talking about the stuff in general. A lot of things are classified as fatal errors shouldn’t be that concerning. They are recoverable in a way or could be made to be recoverable. [crosstalk 00:45:17].

Joe Watkins: The same thing could happen. You said a minute ago if you return for a non existent function call, the same thing would happen that would happen in C. You would be calling functions on null objects wouldn’t you?

Sara Goleman: Well, that depends on where you put that error handling. Right now, that error’s thrown from the bind function path and obviously that can’t just now return something recoverable because the actual caller has nothing to call. If you move that thing down a bit so that the Zend call function I think, if the error is down there then it can just return failure because it wasn’t able to call a function [00:46:00]. More generally though, we added the E recoverable error in like 5-2 or 3 or something like that.

That’s what that’s for is for all these extensions that have been throwing E errors when it’s not completely an E error, but because they don’t know how to deal with it. Those can largely be converted over to E recoverable error. I think that effort should probably be started now. There’s a lot of places in the engine where we can switch those E errors to E recoverable errors. If we get that occurrence of E error down to the things that are genuinely you are effed in the situation then we can turn E recoverable errors into exceptions.

Phil Sturgeon: It seems to me as well, just by trying to convert a lot of … This whole section of us talking is about me trying to work out if the error exception situation or the RFC is really as much as a BC issue as people are suggesting it is right? With these things where people are talking about … One of the thing that are recoverable for fatal, and that really isn’t an issue with BC at all because it’s a case of the only difference you’re going to see at the moment if something’s a fatal error, then you’re going to get an error message pop up saying fatal error, you fucked up. Whereas if you [inaudible 00:47:34] RFC then what you’re going to see is uncaught exception, you fucked up. It will be the same thing but with a back trace right?

Sara Goleman: Well, the trouble with that is when somebody catches it and says I’m on 5.7 so I’m going to catch that exception and I’m going to do some thing about it, but because that bit of C code was originally expecting the request to be aborted, it hasn’t cleaned up after itself [00:48:00]. If you continue on then something is in a state where it shouldn’t be. Maybe you are in the wrong caller reference frame or maybe you have some global that’s been set to null but it wasn’t ever expected to be null. There’s some later on circumstance that’s going to be fucked up.

Phil Sturgeon: Yeah, OK. That makes sense. Joe, anything on that?

Joe Watkins: No.

Phil Sturgeon: Oh OK, well bye. That sounds cool. The reasons I’m interested in [inaudible 00:48:36] is because [Name-pro-miss 00:48:38] is something I’d really fucking love to see. Error exception is obviously something I’m interested in as well. If [Name-pro-miss 00:48:47] is brought by our exception and our exception is going to be such a big issue that it might have to be 5.7 or oh dear God 6, then that’s something that interests me because obviously I want them so I want to know when they might happen. It seems like a bit of a tricky one. Is 5.7 even on the road map yet? Where are we at with 5.6?

Joe Watkins: 5.6 has been brought about. There’s a 5.6 [inaudible 00:49:12].

Sara Goleman: Technically master is 5.7.

Joe Watkins: Yeah. It’s [inaudible 00:49:19].

Sara Goleman: Oh OK.

Joe Watkins: I [inaudible 00:49:22] that 5.6 is reaching feature freeze itch, not quite yet. Don’t do anything to get lazy and big. How far away is the 5.6? Is this all public information that I can find on wiki?

Sara Goleman: Yeah. It is yeah.

Phil Sturgeon: Can you throw me the link for that because I feel like a lot of people don’t know know what where that is. I certainly don’t myself.

Sara Goleman: Well, there’s our release process which is documented in the RFC wiki and it talks about how we want to get a new minor release out each year at roughly the same time each year. We know that 5.5 was released last summer so 5.6 should probably be released this summer [00:50:00].

Phil Sturgeon: Excellent. My memory clearly isn’t good enough to remember that it was summer. That’s the problem.

Sara Goleman: It might have been May. I can’t remember.

Phil Sturgeon: Cool, OK. Well, there we go. 5.6 is going to be 5ish, 6 months away somewhere. Maybe earlier. That sounds interesting to us.

Sara Goleman: Well, ultimately it call comes down to the when it’s ready policy of release.

Phil Sturgeon: OK, so PHP takes the approach of we will aim for this, but we’re busy. It’s not done yet, shoosh, wait.

Sara Goleman: Well, 5.6 for example was supposed to be released in like February or something like that. It got delayed because of, 5.5 is what I meant to say. It got delayed because of I think it was zend optimizer was ultimately a main culprit there. They get released when it gets released.

Phil Sturgeon: Was Zend optimizer tricky to get in? Did you have to crow bar that into place or was it …

Joe Watkins: Well, it’s not really even in. It’s just in the extension folder. You can’t even compile it’s status at the moment.

Sara Goleman: Really?

Joe Watkins: Yeah. The [inaudible 00:51:10].

Phil Sturgeon: It’s literally like a default enabled extension that you don’t realize is an extension. Is that how it works?

Joe Watkins: No, no [crosstalk 00:51:20].

Sara Goleman: It can’t be compiled statically so it’s not even default enabled then.

Joe Watkins: It’s not default loaded. No, you have to configurate with the Zend extension reckon [inaudible 00:51:35] file. Yeah you can’t compile it static.

Phil Sturgeon: Is that likely to change at any point or is it close enough to done?

Joe Watkins: No one’s had a pole request open since about 3 days after it was put on GitHub. Who fixed it? It just doesn’t [inaudible 00:51:57].

Sara Goleman: Oh that’s sad [00:52:00].

Phil Sturgeon: Well maybe now that it’s been brought to memory, someone mentioned that. That sounds like [crosstalk 00:52:07].

Sara Goleman: [inaudible 00:52:06] then if you’re watching get on that or put someone on that.

Phil Sturgeon: Who would be in charge of kicking that process off if [crosstalk 00:52:15].

Sara Goleman: I’m sure Andy can order somebody to do it.

Joe Watkins: Someone needs to get it all done. It will probably fall to Dimitri to actually do it. Most things go to Dimitri.

Sara Goleman: Yeah.

Joe Watkins: Oh poor guy. Well, I think that brings us pretty close to the full hour. We’ve actually been obviously on here for 2 hours because that was a fucking process getting onto Google Plus. I’m glad that it worked out in the end and I’m really grateful that you guys stuck around. Actually before we wander off it seems the double claw is right there over Sara’s right shoulder. It reminds me, MadeInProductions.com is a new website run by myself and Zack Kitzmiller. That guy with the beard that you see on here now and then. Sara’s waving. Make a noise Sara. Thank you. That’s the double claw, she’s pointing to her. If you would like to get a t-shirt with the double claw on it, go to MadeInProductions.com. It’s like 20 bucks and that goes entirely towards my drinking habit and Zack’s children. And Kim gets most of the money to be honest. I’m going to go spend more of that money on her immediately because we’re really late for dinner. Once again I’d really like to thank you guys for joining me on the show. It’s been awesome having you on here and I’m so fucking sorry it took so long to get setup.

Sara Goleman: Thank you Kim for putting up with Phil dicking around with Google Plus.

Joe Watkins: I’ll tell her you said that. Great. Well thank you very much guys and I’ll talk to you soon.

Sara Goleman: Cheers Phil.

Joe Watkins: Cheers.

Sara Goleman: All right I’m just going to hit stop broadcast on that.

Posted in PHP

How will HHVM influence PHP?

Over the last few weeks, there’s been a slew of HHVM related news from the “We are the 98.5%” post from the HHVM team to the Our HHVM Roadmap from the Doctrine team. With the increasing excitement around HHVM, it’s becoming clear that the project is going to play an important role in the evolution of the PHP ecosystem. Even though it’s in it’s early stages, what influences will the HHVM project have on the PHP ecosystem as a whole?

Force the creation of a language spec

In contrast with other languages like Python or JavaScript, PHP has no formal language specification. There’s some extended discussion on this StackOverflow thread with links to PHP internals posts but the final consensus is that there isn’t a defined EBNF grammar for PHP or a “specification” for how things should work. Instead of a spec, the behavior of PHP has become defined by how the Zend interpreter works since it’s been the only viable implementation of the language to date. HHVM changes this situation by introducing another run time for the language, a developer won’t necessarily know if their code will be deployed on Zend or HHVM. Because of this, the community will have to develop a language specification to ensure that any language changes are implemented identically in both run times.

Willingness to introduce BC breakage

One of the hallmarks of PHP has been its strong adherence to backwards compatibility, five year old code written to target PHP4 will generally run today on PHP5+ without any modifications. This has generally been possible because changes to PHP the language didn’t change behavior which would of broken previously working code. Because of this, many of PHP’s long standing syntax issues haven’t been fixed and changes to the standard library have been largely avoided. If HHVM emerges as an alternative runtime, some of this hesitation should be removed since if only “newer” code will run on HHVM it would be conceivable to introduce a “HHVM compat” mode into the Zend implementation which could include BC breaking syntax changes.

JIT into Zend

Just in-time compilation has been shown to dramatically increase the execution speed of interpretted programming languages and it’s one of the key benefits of the HHVM interpretter. HHVM identities “hot code” which is repeatedly executed and then compiles those blocks to native code. The result of this is that those “hot code” sections execute faster since they’re running native code instead of the interpreted op codes. As HHVM becomes more popular, I think we’ll see cross pollination of JIT into Zend similar to how Firefox adopted JIT after Google released Chrome.

Anyway, it’s still early but the emergence of HHVM as an alternative PHP runtime will definitely have a positive influence on the PHP ecosystem. From technology sharing to increased competition, the future is bright and I’m excited to see how PHP evolves in the next few years.