1. the JVM is an open, stable, mature, fast platform for server applications.
2. Facebook are not moving off PHP any time soon.
3. For stuff outside its written-in-C standard lib, PHP is quite slow. PHP's garbage collection, JITting etc is nowhere near as advanced as the JVM's.
4. Since porting dynamic languages to the JVM is a well-worn pathway, why not try porting PHP and see how it performs?
If Facebook can reduce their CPU and RAM requirements by just 10%, it pays for itself many times over vs the stock PHP runtime. And based on what I've seen with JRuby (going from 50Mb MRI runtimes down to 2.5Mb runtimes that are 3-10x faster) that's entirely reasonable.
I didn't mean 2.5Mb per copy of the JVM. I meant per runtime within the JVM. These are run as threads, rather than processes.
So we're really comparing
n instances of MRI * 50Mb
vs 1 JVM + (n * 2.5Mb)
Where the cost of the JVM itself is amortised over the application instances.Sorry, what I said originally is easily misleading.
It seems easier to me to port PHP to Rhino or node.js than to bring PHP to the JVM. Especially considering CoffeeScript, PHP just can't keep up.