php - quién - tabla de codigo bytecode
¿Por qué PHP usa cachés de códigos de operación mientras que Java compila a archivos de códigos de bytes? (5)
Desde mi punto de vista, tanto PHP como Java tienen una estructura similar. Al principio, escribe un código de alto nivel, que luego debe traducirse en un formato de código más simple para que lo ejecute una máquina virtual. Una diferencia es que PHP trabaja directamente desde los archivos de código fuente, mientras que Java almacena el bytecode en archivos .class, desde donde la VM puede cargarlos.
Hoy en día crecen los requisitos para acelerar la ejecución de PHP, lo que lleva a las personas a creer que sería mejor trabajar directamente con los códigos de operación y no pasar por el paso de compilación cada vez que un usuario acceda a un archivo.
La solución parece ser una carga de los llamados aceleradores , que básicamente almacenan los resultados compilados en caché y luego usan los códigos de operación almacenados en caché en lugar de compilar de nuevo.
Otro enfoque, hecho por Facebook, es compilar completamente el código PHP a un idioma diferente.
Entonces mi pregunta es, ¿por qué nadie en el mundo de PHP está haciendo lo que hace Java? ¿Hay algunos elementos dinámicos que realmente necesitan ser recompilados cada vez o algo así? De lo contrario, sería más inteligente compilar todo cuando el código entre en producción y luego simplemente trabaje con eso.
Creo que todos ustedes están mal informados. HHVM no es un compilador de otro languague es una máquina virtual en sí misma. La confusión se debe a que Facebook utiliza para compilar a c ++, pero ese enfoque fue lento para los requisitos de los desarrolladores (diez minutos compilando solo para probar algunas cosas pequeñas).
La diferencia más importante es que la JVM tiene una especificación explícita que cubre completamente el bytecode. Esto hace que los archivos de bytecode sean portátiles y útiles para algo más que la ejecución mediante una implementación de JVM específica.
PHP ni siquiera tiene una especificación de idioma . Los códigos de operación de PHP son un detalle de implementación de un motor PHP específico, por lo que no puedes hacer nada realmente interesante con ellos y no tiene sentido hacerlos más visibles.
Los códigos de operación PHP no son lo mismo que los archivos de clase Java. Los archivos de clase Java están bien especificados y son portátiles entre las máquinas. Los códigos de operación de PHP no son portátiles de ninguna manera. Tienen direcciones de memoria horneadas en ellos, por ejemplo. Son estrictamente un detalle de implementación del intérprete de PHP, y no deben considerarse como bytecode de Java.
¿Tiene que ser así? No, probablemente no. Pero el código fuente de PHP es un desastre, y no existe el deseo, ni la voluntad política en la comunidad interna de PHP para que esto suceda. Creo que se habló de preparar un caché de código de operación en PHP 6, pero PHP 6 murió, y no sé el estado de esa idea.
Referencia : Escribí phc, así que estuve bastante inmerso en la implementación / compilación de PHP durante algunos años.
No es del todo cierto que nadie en el mundo de PHP esté haciendo lo que hace java. Proyectos como el servidor de aplicaciones de Alexey Zakhlestin proporcionan un grado de persistencia más parecido a un contenedor de servlets de Java (aunque su inspiración es más de Ruby''s Rack y de Python''s WSGI que Java)
PHP no usa un mecanismo estándar para los códigos de operación. Ojalá esté pegado a una pila VM (python, java) o una máquina virtual de registro (x86, perl6, etc.). Pero utiliza algo absolutamente local y allí radica el problema.
Utiliza una lista conectada en memoria que da como resultado que cada código de operación tenga un resultado -> op1 -> op2 y ->. Ahora cada uno de ellos son constantes o entradas en una tabla temporal, etc. Estos punteros no se pueden serializar de ninguna manera.
Ahora, la gente ha logrado esto usando elementos como pecl / bcompiler que descarga el flujo en el disco.
Pero las clases lo hacen aún más complicado, lo que significa que hay posibles fragmentos de código como
if(<conditon>)
{
class XYZ() { }
}
else
{
class XYZ() { }
}
class ABC extends XYZ {}
Lo que significa que una gran cantidad de decisiones sobre clases y funciones solo se pueden realizar en tiempo de ejecución: algo como Java se ahogaría en dos clases con el mismo nombre, que se definen condicionalmente en el tiempo de ejecución. Básicamente, el código de caché de herencia y clase de APC es quizás la parte más complicada y propensa a errores de la base de código. Cada vez que se almacena en caché una clase, todos los miembros heredados deben eliminarse antes de que se pueda guardar en el caché del código de operación.
El problema del puntero no es insuperable. Hay un apc_bindump que nunca me he molestado en arreglar para cargar entradas de caché completas del disco directamente cada vez que se realiza un reinicio. Pero es doloroso depurar todo eso para obtener algo que todavía necesita localizar todos los punteros del sistema: el caso de apache es demasiado fácil, porque todos los procesos php tienen los mismos punteros del sistema debido al comportamiento de la horquilla. Las viejas versiones de fastcgi eran más lentas porque solían bifurcarse primero e iniciar php más tarde; el php-fpm lo arreglaba al revés.
Pero, finalmente, lo que realmente falta en PHP es la voluntad de inventar un formato de código de bytes, descartar el motor actual y todos los módulos, reescribirlo usando una pila VM y crear un JIT. Ojalá tuviera tiempo, los chicos de FB casi están allí con su HHVM de hiphop. Que sacrifica eval () para un rendimiento más rápido, que es un sacrificio justo :)
PD: soy el tipo que no puede encontrar tiempo para actualizar APC 5.4 correctamente