Running Java in Node.js with WebAssembly

Hola a todos. Bienvenidos a mi charla sobre cómo ejecutar Java en Node.js con WebAssembly. Soy Brendan. Actualmente soy ingeniero de investigación en Expo, pero antes de eso, trabajé en herramientas de desarrollo para CloudFloat workers.

Entonces, antes de comenzar, ¿por qué querrías hacer esto? Muchas organizaciones tienen mucho código Java, y a medida que adoptan tecnologías más nuevas como Node.js o CloudFloat workers, mantener la interoperabilidad con este código existente se vuelve importante. Además, muchas experiencias web interactivas solían estar impulsadas por Java, pero los navegadores modernos bloquean los applets de Java, así que muchos sitios ya no funcionan. Sería bueno si no tuviéramos que reescribir todo.

Comencemos desde lo básico. Este es un programa Java simple que imprime en la consola. Lo compilas con el compilador de Java que produce un archivo de clase y puedes ejecutarlo con el comando de Java. Java aquí es un entorno de ejecución, que es ligeramente diferente de los programas en C y Go, donde estás compilando para una arquitectura específica. Como mencioné, este entorno de ejecución es la máquina virtual de Java, que toma estos archivos de clase, que son portátiles e independientes de la plataforma, que contienen instrucciones de la JVM en lugar de instrucciones específicas de la arquitectura, y luego las ejecuta. Lo importante aquí es que no tiene que ser solo Java. Tú puedes compilar otros lenguajes como Scala y Kotlin al mismo bytecode de la JVM también.

La JVM es una máquina de pila, así que echemos un vistazo rápido a cómo se ve esto para este simple programa de suma. Así que, los parámetros de la función se almacenan como locales, y comenzamos la primera instrucción, que empuja un local a la pila, pasamos a la siguiente instrucción, y luego esta instrucción de suma saca dos valores de la pila, los suma, y luego empuja el resultado de nuevo a la pila.

Así que, como mencioné, la JVM proporcionó un entorno de ejecución muy portátil. Solías poder ejecutar applets en el navegador a través de un plugin. Los navegadores comenzaron a deshabilitar applets, introdujeron esta cosa llamada Java Web Start en su lugar, pero aún tenemos muchas advertencias de seguridad, como, no muy agradables aquí. Aún tienes que instalar el entorno de ejecución de Java, y no estaba integrado en los navegadores. Hoy en día, por supuesto, hacemos todo este tipo de cosas interactivas con JavaScript en su lugar, y los motores de JavaScript se están volviendo muy potentes. Así que, los motores modernos de JavaScript utilizarán compilación just-in-time. Este es un pipeline simplificado del motor V8 de Chrome. Así que, lo que sucede es que primero interpretas el JavaScript y luego observas qué tipos de funciones se llaman con frecuencia, y luego tú generas código optimizado como resultado de eso. Con todos estos motores de JavaScript eficientes, se vuelve posible potencialmente ejecutar otros lenguajes en el navegador también utilizando el mismo motor.

Así que, había esta cosa llamada Asm.js, que fue diseñada como un objetivo de compilación para otros lenguajes. Era un subconjunto extremadamente optimizable de JavaScript, y los navegadores que no soportaban esta cosa de Asm.js aún podían tratarlo como JavaScript regular y ejecutarlo sin, como, tiempo de ejecución adicional. Y lo que la gente encontró es que cuando, como, compilabas programas en C a este subconjunto optimizable, generalmente podías, como, obtener un rendimiento casi nativo mientras aún, como, integrabas con JavaScript. Pero había más que se podía hacer aquí. Así que, aquí es donde entra WebAssembly.

WebAssembly entra en juego. WebAssembly es una máquina de pila, como la JVM, pero con un conjunto de instrucciones diferente. Así que, es tipado, por lo que es altamente optimizable, pero mejora sobre Asm.

js con este nuevo formato binario, y también soporta compilación en streaming así como características modernas de CPU como SIMD y enteros de 64 bits. Así que, {{^}}WebAssembly tiene dos formatos intercambiables. Tienes el formato binario a la izquierda y este texto legible por humanos a la derecha.

Y en todos los ejemplos futuros, solo vamos a usar el formato de texto porque es mucho más fácil de leer. Así que, si volvemos al pipeline, porque ahora sabemos estos tipos de antemano podemos ir directamente al código de máquina optimizado. Así que, no tenemos que, como, observar las ejecuciones y ver qué está pasando primero. WebAssembly se ejecuta en todas partes hoy en día. Así que, navegadores, por supuesto, Node.js, otros entornos de ejecución de JavaScript en el servidor, como CloudFlow Workers y todo eso, y entornos embebidos también, así que puedes ejecutarlo dentro de tus programas en Rust o Go o lo que sea. Sí. Así que, de eso se tratará este proyecto. Vamos a estar compilando bytecode de la JVM a WebAssembly para que Java o cualquier otro lenguaje que apunte a la JVM pueda ejecutarse en Node.

Así que, ahora que hemos echado un vistazo rápido a la historia, veamos cómo son estos archivos de clase en realidad. Así que, si volvemos al ejemplo de compilación simple, ¿qué contiene este archivo hello.class? Un lío binario. Podemos ver los nombres de algunas otras clases, pero, sí, eso no es muy útil. Así que, los archivos de clase en sí están empaquetados en archivos jar, y cada archivo de clase se ve algo así como esto, donde tienes este pool de constantes, tienes algunos metadatos, tienes algunos campos, y tienes el código real en sí.

Los métodos cada uno tiene una especie de descriptor de método que describe los tipos de las entradas y las salidas. Así que, tenemos este tipo de parámetros entre paréntesis y luego el tipo de retorno después. Y los tipos primitivos de Java se mapean a estas pequeñas letras, así que, como, byte es B, char es C, long es J, por supuesto, y así sucesivamente.

Así que, ahora que podemos analizar estos archivos de clase, hablemos sobre la compilación y la llamada a funciones con ellos. Así que, tenemos los descriptores de métodos, tenemos el bytecode. Así que, podemos comenzar a transformarlo a WebAssembly. Para hacer esto, podemos simplemente hacer un patrón de coincidencia en los descriptores que hemos analizado anteriormente y convertirlos a tipos de WebAssembly, y de manera similar para las instrucciones, podemos simplemente tomar las instrucciones de la JVM y convertirlas a WebAssembly. Esto va a ser realmente fácil. Y eso es más o menos todo lo que necesitamos para la compilación básica. Cuando tienes esto, para ejecutarlo, puedes simplemente envolverlo con un módulo de WebAssembly, y luego puedes exportarlo, y luego tenemos este formato de texto que en realidad no podemos ejecutar, así que lo convertimos al formato binario, y obtenemos este código de Node.js, que es súper agradable, porque solo tenemos que leer el archivo, podemos compilar eso en un módulo de WebAssembly, instanciarlo y llamar a sus exportaciones.

Genial, esto es tan fácil. Hemos terminado. Oh, espera, un momento, no, no hemos terminado. Así que, también podemos llamar a la función desde dentro de WebAssembly, lo cual es agradable, pero espera un momento, tenemos un primer problema. Java te permite hacer sobrecargas de métodos, donde puedes tener el mismo método, el mismo nombre, pero solo, como, diferentes parámetros en su lugar. Y podemos implementar esto en WebAssembly. Podemos simplemente poner los descriptores de métodos en los nombres de las funciones y tratarlos como funciones separadas. Eso funciona, está bien. Pero hay una pequeña sutileza aquí. En, a pesar de que estamos añadiendo dos de las mismas cosas, en el ejemplo de enteros, el segundo entero se carga desde el índice uno, y en el ejemplo de dobles, el segundo doble se carga desde el índice dos. Esta es una especie de peculiaridad de cómo Java almacena estos locales. Así que, Java trata los locales como slots de cuatro bytes, y los ints son una palabra cada uno, los dobles son dos palabras, y el problema es que WebAssembly espera valores tipados únicos para locales. Así que, cuando creas un local en WebAssembly, tienes que definir su tipo de antemano, y solo puede ser ese tipo.

Esto se complica aún más, porque si tomamos este, como, ejemplo aquí, los slots locales se reutilizan si las variables salen del alcance. Así que, una sola palabra es referenciada como un int, y la primera mitad de un double en la misma función. Esto definitivamente no está permitido en WebAssembly.

Así que, la solución aquí es que podemos reasignar los locales de WebAssembly. Lo que podemos hacer es para cada par único de índice y tipo de la JVM, podemos crear ese par como su propio local en su lugar.

Así que, compilar funciones es genial, pero casi todos los programas tendrán alguna lógica condicional para ti. Este es un programa de ejemplo con una declaración if. Lo que estamos haciendo aquí es devolver true si el valor es mayor que dos. Probablemente no escribiría algo así, pero podemos ver el bytecode correspondiente de Java a la derecha.

Así que, vamos a recorrer un ejemplo de ejecución de esta función donde el valor es tres. Así que, tenemos el parámetro en el local cero, y tenemos el valor de resultado en el local uno. Así que, hemos llegado a este punto en la ejecución donde hemos alcanzado esta instrucción de comparación de enteros if menor que o igual a, y tenemos que evaluar si tres es menor o igual a dos. Así que, ese no es el caso, así que no vamos a tomar este salto. En su lugar, simplemente continuamos a la siguiente instrucción, y almacenamos true en el resultado. Si volvemos, y en su lugar el valor que pasamos a la función es uno, entonces sí queremos tomar esta rama, así que avanzamos cinco instrucciones y saltamos más allá de la declaración if.

El problema es que WebAssembly no tiene gotis, así que no podemos implementar este tipo de salto basado en ramificación. En su lugar, WebAssembly necesita un flujo de control estructurado. Así que, esto básicamente significa igual que las declaraciones if regulares que verías en JavaScript. Así que, para tomar este bytecode de la JVM y convertirlo a esto, necesitamos recuperar la declaración if de alguna manera.

Veamos un ejemplo más interesante. Así que, esto tiene algunas declaraciones if anidadas y un flujo de control bastante interesante. Así que, para el análisis, un gráfico de flujo de control es muy útil. Un gráfico de flujo de control es básicamente cada nodo es una instrucción, y tienes un borde si una instrucción conduce a otra. Podemos agrupar instrucciones sin flujo de control intermedio en bloques básicos. Esto no afecta los resultados del análisis, solo lo hace más eficiente y también es mucho más fácil ver lo que está sucediendo también.

Así que, cuando estamos recuperando declaraciones if, lo que nos interesa es encontrar los encabezados de esas declaraciones if, dónde comienzan, y luego los nodos de seguimiento donde las ramas se unen nuevamente. Queremos permitir declaraciones anidadas también. Vamos a repasar algunas definiciones. El nodo A domina a B si el control debe pasar por A antes de llegar a B. El nodo A domina estrictamente a B si A domina a B y A no es igual a B.

Y luego el nodo A es el dominador inmediato de B si A domina estrictamente a B, pero no domina a ningún otro dominador estricto de B. Así que, eso es un poco de sopa de palabras. Pero básicamente, el dominador inmediato es el dominador estricto más cercano. Así que, en este ejemplo, el dominador inmediato del nodo 5 sería 0. Para recuperar realmente los nodos de seguimiento, tenemos este algoritmo aquí, que recorre el gráfico en reversa, en orden post orden de profundidad.

Así que, las estructuras anidadas se manejan primero. Tenemos este conjunto de nodos no resueltos, que son los nodos de encabezado bidireccionales para los cuales aún no hemos encontrado un nodo de seguimiento, y decimos que el nodo de seguimiento es el nodo máximo con dos más en bordes que tiene un encabezado como el dominador inmediato. Si lo encontramos, marcamos todos los nodos no resueltos con ese seguimiento, y si no, lo agregamos al conjunto no resuelto. Y utilizando este algoritmo, terminamos con suficiente información para reconstruir las declaraciones if originales. El ensamblaje web resultante se vería algo así.

Como antes, las instrucciones de ramificación, si llegas a una declaración if, tomas la rama si la parte superior de la pila no es cero. Así que, eso funciona genial para la mayoría de los condicionales, pero Java también tiene estos condicionales de cortocircuito también. Verás esto en JavaScript también. Y B no se evalúa si A es falso. Esto produce un gráfico de flujo de control que se ve algo así, y lo que tenemos aquí es algo llamado flujo de control no estructurado o irreducible.

Si quisiéramos aplicar una lógica similar a lo que hicimos antes, es posible que necesitemos duplicar el bloque dos. En su lugar, podemos buscar patrones en estos, lo que estos condicionales de cortocircuito producen, y luego podemos aplicar reescrituras al gráfico repetidamente hasta que no tengamos más cambios. Y WASM nos permite tratar las declaraciones if como expresiones también. Así que, puedes devolver valores de las ramas, y luego, después de la evaluación, lo que tengo en negrita aquí se colapsará a un solo valor en la pila, y luego podemos usar eso para ramificar en su lugar. Y eso nos permitirá producir estos condicionales de cortocircuito.

Bien, así que además de los condicionales, la mayoría de los programadores tendrán bucles también. Así que, la característica definitoria de un bucle en un gráfico de flujo de control es un borde de retroceso. Así que, este es un borde hacia el mismo punto o un punto anterior en el gráfico. Cada borde de retroceso corresponde a un bucle. Tenemos dos tipos diferentes de bucles. Tenemos bucles de prueba previa que son como tus bucles while tradicionales, y tenemos bucles de prueba posterior, que son como los bucles do-while.

Veamos un poco más de flujo de control complicado nuevamente. Así que, lo que tenemos aquí es que tenemos una declaración if de antes, donde el nodo 0 es el nodo de encabezado, y el nodo 4 es el nodo de seguimiento. Este es un bucle de prueba posterior, así que el nodo de encabezado es 0, el nodo de retención es 4, y el nodo de seguimiento es 5. Y luego para un bucle de prueba previa, tenemos el encabezado de 2, el nodo de retención es 3, y nuestro nodo de seguimiento es 4. Así que nuevamente, un par más de definiciones. El intervalo es el subgráfico más grande con una sola entrada donde todos los ciclos contienen esa única entrada. Así que, en este ejemplo, tenemos tres intervalos aquí, cada uno con dos nodos. Y con una selección cuidadosa de estos encabezados de intervalo, podemos particionar el gráfico. Para recuperar bucles de nuestros gráficos de flujo de control, necesitamos este tipo de secuencias derivadas de tuplas, de gráficos y sus intervalos. Así que, decimos que los nodos del gráfico I son los intervalos del gráfico anterior, y agregamos bordes al gráfico I si existe un borde entre los intervalos del gráfico anterior. Y seguimos repitiendo esto hasta que no tengamos cambios, y esto produce la secuencia de tuplas.

Así que, esta es una secuencia de ejemplo que tenemos aquí. 0 es nuestro gráfico original, 1 es después de una iteración, y luego 2 es después de la segunda iteración. Y hemos llegado a un gráfico trivial al final. Si no hubiéramos llegado a un gráfico trivial con solo un bloque, diríamos que tenemos un flujo irreducible.

Y nuevamente, tenemos este algoritmo donde podemos, para cada una de estas tuplas en la secuencia derivada, podemos mirar cada intervalo, buscar el borde de retroceso en el mismo intervalo, y luego tenemos, podemos averiguar cuál es el encabezado y el nodo de retención, y luego, basándonos en algunos patrones, podemos averiguar qué tipo de bucle es, y luego podemos averiguar el nodo de seguimiento, basado en si es un bucle de prueba previa o posterior.

Para implementar realmente estos tipos de bucles, Wasm nos da dos tipos de bloque adicionales. Así que, el bloque se comporta como declaraciones break, el bucle se comporta como declaraciones continue cuando ramificas hacia ellos, y luego, usando estas dos cosas diferentes, podemos implementar bucles de prueba previa y posterior. Finalmente, nos falta algo importante. Java es un lenguaje orientado a objetos, así que necesitamos objetos también. Antes de poder hablar sobre objetos, necesitamos hablar sobre la memoria del programa. Así que, la memoria del programa generalmente se divide en dos secciones, la pila compuesta de variables locales que viven durante la duración de una llamada a función, y el montón, que es un montón desorganizado de objetos que viven durante la duración del programa. La pila contiene referencias a objetos en el montón, y así WebAssembly, si queremos un montón, podemos usar las memorias lineales, y esto aquí crea una memoria que tiene un tamaño de 64 KB.

Veamos una clase simple con dos campos. Tenemos un campo entero y tenemos un campo doble. Los campos enteros ocuparán cuatro bytes y los dobles ocuparán ocho bytes. Los campos se almacenan continuamente en nuestra memoria.

Cuando creamos una nueva instancia del objeto, asignamos espacio para él, y hay muchas estrategias de asignación diferentes, pero para empezar podemos implementar un asignador bump. Así que, esto tiene un puntero global siguiente, y cuando asignas un tamaño específico, añadimos ese tamaño al puntero global siguiente y devolvemos el puntero original. No hay recolección de basura aquí, simplemente seguimos asignando, seguimos asignando.

Podemos usar esto con nuestra clase adder, así que sabemos que el tamaño del adder va a ser de 12 bytes, así que simplemente creamos una constante en la pila y luego llamamos a nuestra asignación. ¿Qué pasa si queremos agregar métodos de instancia? Entonces, tenemos este método add aquí que suma los dos campos, y produce el siguiente bytecode, pero ¿qué es esto, como, una cosa de carga cero? Así que, esto está cargando el parámetro implícito this, que podrías haber visto en, como, otros lenguajes como Python mismo. En Java, en realidad no tienes que escribirlo, pero siempre está ahí.