Rápido significa poder ejecutar Node.js, ya que necesitamos poder dar una situación donde el código no solo se genera en tiempo de ejecución, sino que también se cambia en tiempo de ejecución, tal vez modificado en el lugar, o tal vez simplemente eliminado y puesto en otro lugar. Esto también sucede al ejecutar código con V8, porque el código en sí es recolector de basura y se mueve por la memoria con el tiempo.
Y luego queríamos construir algo escalable. Lo que esto significa es que, aunque les mostré solo un montón de palabras amarillas, esto puede funcionar en bases de código mucho más grandes. Queríamos construir algo que pueda trabajar con programas en el mundo real, lo que significa que queremos apoyar la multiprocesamiento, multihilo, miles de archivos, y todo tipo de características que son efectivamente utilizadas por programas que son reales, no solo juguetes.
Para darles una idea de lo que hemos visto hasta ahora, Chirpx es este entorno en el que toda la ejecución ocurre. Y es todo del lado del cliente. Todo está en el navegador. No hay un componente del lado del servidor haciendo la ejecución por nosotros. Esto no es un truco. Y lo primero que se inicia es Bash. Así que Bash es el proceso padre. Y luego Bash en sí puede generar subprocesos, procesos hijos, y les mostré GCC y Python, y todos estos son completamente independientes de otros espacios. Tienen su propio código y tienen sus propios datos.
Pero el problema es que, desde el punto de vista del sistema, realmente no sabemos qué es código y qué es datos. Estas dos cosas son solo bytes. Es solo datos antiguos en memoria. Y para resolver este problema, tenemos en realidad un motor de ejecución de dos niveles. El primer nivel es un intérprete, y el segundo nivel es un motor JIT real que puede generar código altamente optimizado. Y el intérprete es capaz de ejecutar código sin ninguna información. Comenzará desde la primera instrucción y la pasará a la siguiente y así sucesivamente. Y mientras hace esto, también construirá los metadatos internamente sobre cómo está estructurado el código. Y con eso, ahora es posible activar el motor JIT para generar código optimizado y robusto a partir de esto.
Y eventualmente, todas estas aplicaciones necesitarán llegar al navegador de alguna manera porque necesitamos mostrar texto en pantalla, por ejemplo. Y esto sucede como se esperaría en un sistema nativo a través de llamadas al sistema. Y las llamadas al sistema, las implementamos nosotros mismos. Así que lo que han visto hasta ahora no es un kernel de Linux. Es un ABI compatible con Linux, por lo que puede ejecutar cualquier ejecutable de Linux, pero no es Linux en sí. Y la llamada al sistema es el lugar donde nos detenemos e implementamos la llamada al sistema manualmente para que puedan interactuar con el navegador. Y ahora podrían preguntarse por qué no ejecutamos todo en el JIT, ya que es más probablemente más eficiente.
Comments