En esta página, se proporciona una descripción general de alto nivel de los problemas y desafíos específicos de escribir reglas de Bazel eficientes.
Resumen de requisitos
- Suposición: Precisión, capacidad de procesamiento, facilidad de uso y latencia
- Suposición: Repositorios a gran escala
- Suposición: Lenguaje de descripción similar a la COMPILACIÓN
- Histórica: La separación estricta entre la carga, el análisis y la ejecución está desactualizada, pero aún afecta a la API
- Funciones intrínsecas: La ejecución remota y el almacenamiento en caché son difíciles
- Funciones intrínsecas: el uso de información de cambios para compilaciones incrementales correctas y rápidas requiere patrones de codificación inusuales
- Funciones intrínsecas: Evitar el tiempo cuadrático y el consumo de memoria es difícil
Supuestos
Estas son algunas suposiciones realizadas sobre el sistema de compilación, como la necesidad de precisión, la facilidad de uso, la capacidad de procesamiento y los repositorios a gran escala. En las siguientes secciones, se abordan estas suposiciones y se ofrecen lineamientos para garantizar que las reglas se escriban de manera efectiva.
Apunta a la precisión, la capacidad de procesamiento, la facilidad de uso y la latencia
Suponemos que el sistema de compilación debe ser, en primer lugar, correcto con respecto a las compilaciones incrementales. Para un árbol de fuentes determinado, el resultado de la misma compilación siempre debe ser el mismo, independientemente de cómo se vea el árbol de resultados. En la primera aproximación, esto significa que Bazel necesita saber cada entrada que se incluye en un paso de compilación determinado para poder volver a ejecutar ese paso si cambia alguna de las entradas. Existen límites en cuanto a cómo puede ser la respuesta correcta de Bazel, ya que filtra información, como la fecha y hora de la compilación, y omite ciertos tipos de cambios, como los cambios en los atributos del archivo. La zona de pruebas ayuda a garantizar la precisión, ya que evita las lecturas a archivos de entrada no declarados. Además de los límites intrínsecos del sistema, existen algunos problemas de precisión conocidos, la mayoría de los cuales están relacionados con el conjunto de archivos o las reglas de C++, que son problemas difíciles. A largo plazo, tenemos que tomar medidas para solucionarlos.
El segundo objetivo del sistema de compilación es tener una capacidad de procesamiento alta. Estamos ampliando de forma permanente los límites de lo que se puede hacer dentro de la asignación de máquina actual para un servicio de ejecución remota. Si el servicio de ejecución remota se sobrecarga, nadie puede realizar el trabajo.
La facilidad de uso es lo siguiente. De varios enfoques correctos con la misma huella (o una similar) del servicio de ejecución remota, elegimos el que sea más fácil de usar.
La latencia denota el tiempo que se tarda desde que se inicia una compilación hasta que se obtiene el resultado deseado, ya sea un registro de una prueba aprobada o fallida, o un mensaje de error que indica que un archivo BUILD tiene un error tipográfico.
Ten en cuenta que estos objetivos a menudo se superponen. La latencia es una función tanto de la capacidad de procesamiento del servicio de ejecución remota como de la corrección relevante para la facilidad de uso.
Repositorios a gran escala
El sistema de compilación debe operar a la escala de repositorios grandes, donde una gran escala significa que no cabe en un solo disco duro, por lo que es imposible confirmar la compra completa en casi todas las máquinas de desarrollador. Una compilación de tamaño mediano deberá leer y analizar decenas de miles de archivos BUILD y evaluar cientos de miles de globs. Si bien es teóricamente posible leer todos los archivos BUILD en una sola máquina, aún no hemos podido hacerlo en un tiempo y memoria razonables. Por lo tanto, es fundamental que los archivos BUILD se puedan cargar y analizar de forma independiente.
Lenguaje de descripción similar a BUILD
En este contexto, asumimos que el lenguaje de configuración es similar al de los archivos BUILD en la declaración de las reglas binarias y de la biblioteca, y sus interdependencias. Los archivos BUILD se pueden leer y analizar de forma independiente, y evitamos incluso buscar archivos de origen siempre que sea posible (excepto si existen).
Lugar histórico
Hay diferencias entre las versiones de Bazel que causan desafíos, y algunas de ellas se describen en las siguientes secciones.
La separación estricta entre la carga, el análisis y la ejecución está desactualizada, pero aún afecta a la API
Técnicamente, es suficiente que una regla conozca los archivos de entrada y salida de una acción justo antes de que la acción se envíe a la ejecución remota. Sin embargo, la base de código original de Bazel tenía una separación estricta de paquetes de carga, analizaba reglas con una configuración (básicamente marcas de línea de comandos) y solo ejecutaba acciones. Esta distinción sigue siendo parte de la API de reglas en la actualidad, aunque el núcleo de Bazel ya no la requiere (más detalles a continuación).
Esto significa que la API de reglas requiere una descripción declarativa de la interfaz de la regla (qué atributos tiene y tipos de atributos). Existen algunas excepciones en las que la API permite que se ejecute código personalizado durante la fase de carga para procesar nombres implícitos de archivos de salida y valores implícitos de atributos. Por ejemplo, una regla java_library llamada "foo" genera implícitamente un resultado llamado "libfoo.jar", al que se puede hacer referencia desde otras reglas en el gráfico de compilación.
Además, el análisis de una regla no puede leer ningún archivo de origen ni inspeccionar el resultado de una acción; en cambio, necesita generar un gráfico bipartito dirigido parcial de pasos de compilación y nombres de archivos de salida que solo se determina a partir de la regla y sus dependencias.
Intrínseco
En las siguientes secciones, se describen algunas propiedades intrínsecas que dificultan la escritura de reglas, y algunas de las más comunes.
La ejecución remota y el almacenamiento en caché son difíciles
La ejecución remota y el almacenamiento en caché mejoran los tiempos de compilación en repositorios grandes en casi dos órdenes de magnitud en comparación con ejecutar la compilación en una sola máquina. Sin embargo, la escala a la que debe funcionar es sorprendente: el servicio de ejecución remota de Google está diseñado para manejar una gran cantidad de solicitudes por segundo, y el protocolo evita cuidadosamente los recorridos y el trabajo innecesarios por parte del servicio.
En este momento, el protocolo requiere que el sistema de compilación conozca todas las entradas de una acción determinada con anticipación. Luego, procesa una huella digital de la acción única y le solicita al programador un acierto de caché. Si se encuentra un acierto de caché, el programador responde con los resúmenes de los archivos de salida; los archivos en sí se abordan con un resumen más adelante. Sin embargo, esto impone restricciones a las reglas de Bazel, que deben declarar todos los archivos de entrada con anticipación.
El uso de información de cambios para compilaciones incrementales rápidas y correctas requiere patrones de programación inusuales
Anteriormente, argumentamos que, para ser correctos, Bazel necesita conocer todos los archivos de entrada que se incluyen en un paso de compilación para detectar si ese paso aún está actualizado. Lo mismo ocurre con la carga de paquetes y el análisis de reglas. Además, diseñamos Skyframe para controlar esto en general. Skyframe es una biblioteca de grafos y un framework de evaluación que toma un nodo objetivo (como “compilar //foo con estas opciones”) y lo divide en las partes que lo constituyen, que luego se evalúan y combinan para obtener este resultado. Como parte del proceso, Skyframe lee los paquetes, analiza las reglas y ejecuta acciones.
En cada nodo, Skyframe rastrea exactamente qué nodos usa cada nodo para calcular su propio resultado, desde el nodo objetivo hasta los archivos de entrada (que también son nodos de Skyframe). Tener este gráfico representado de forma explícita en la memoria permite que el sistema de compilación identifique exactamente qué nodos se ven afectados por un cambio determinado en un archivo de entrada (incluida la creación o eliminación de un archivo de entrada) haciendo la cantidad mínima de trabajo para restablecer el árbol de salida a su estado previsto.
Como parte de esto, cada nodo realiza un proceso de descubrimiento de dependencias. Cada nodo puede declarar dependencias y, luego, usar el contenido de esas dependencias para declarar aún más dependencias. En principio, esto se asigna a un modelo de subproceso por nodo. Sin embargo, las compilaciones medianas contienen cientos de miles de nodos de Skyframe, lo que no es fácil con la tecnología actual de Java (y, por razones históricas, actualmente estamos vinculados al uso de Java, por lo que no hay subprocesos ligeros ni continuaciones).
En su lugar, Bazel usa un grupo de subprocesos de tamaño fijo. Sin embargo, eso significa que, si un nodo declara una dependencia que aún no está disponible, es posible que debamos anular esa evaluación y reiniciarla (posiblemente en otro subproceso) cuando la dependencia esté disponible. A su vez, esto significa que los nodos no deben hacer esto de forma excesiva; un nodo que declara N dependencias en serie puede reiniciarse N veces, lo que tarda O(N^2) tiempo. En cambio, nuestro objetivo es la declaración masiva de dependencias por adelantado, que a veces requiere volver a organizar el código o incluso dividir un nodo en varios nodos para limitar la cantidad de reinicios.
Ten en cuenta que esta tecnología no está disponible actualmente en la API de reglas. En su lugar, la API de reglas aún se define mediante los conceptos heredados de las fases de carga, análisis y ejecución. Sin embargo, una restricción fundamental es que todos los accesos a otros nodos deben pasar por el framework para que pueda hacer un seguimiento de las dependencias correspondientes. Sin importar el lenguaje en el que se implemente el sistema de compilación o en el que se escriban las reglas (no es necesario que sean las mismas), los autores de reglas no deben usar bibliotecas ni patrones estándar que omitan Skyframe. En el caso de Java, esto significa evitar java.io.File, así como cualquier forma de reflexión y cualquier biblioteca que lo haga. Las bibliotecas que admiten la inserción de dependencias de estas interfaces de bajo nivel aún deben configurarse correctamente para Skyframe.
Esto sugiere, en primer lugar, que evites exponer a los autores de las reglas a un entorno de ejecución de lenguaje completo. El peligro del uso accidental de estas APIs es demasiado grande. Varios errores de Bazel en el pasado se debían a reglas que usaban APIs no seguras, incluso si las reglas las escribían el equipo de Bazel o algún otro experto en el dominio.
Evitar el tiempo cuadrático y el consumo de memoria es difícil
Para empeorar la situación, además de los requisitos que impone Skyframe, las restricciones históricas de uso de Java y la obsolescencia de la API de reglas, ingresar accidentalmente un tiempo cuadrático o consumo de memoria es un problema fundamental en cualquier sistema de compilación basado en reglas binarias y de biblioteca. Existen dos patrones muy comunes que generan un consumo de memoria cuadrática (y, por lo tanto, un consumo de tiempo cuadrático).
Cadenas de reglas de biblioteca: Considera el caso de una cadena de reglas de biblioteca, A depende de B, C, etcétera. Luego, queremos calcular alguna propiedad sobre el cierre transitivo de estas reglas, como la ruta de clase del entorno de ejecución de Java o el comando del vinculador de C++ para cada biblioteca. En concreto, podemos tomar una implementación de lista estándar; sin embargo, esto ya presenta el consumo de memoria cuadrática: la primera biblioteca contiene una entrada en la ruta de clase, la segunda, la tercera y así sucesivamente, para un total de 1 + 2 + 3 +...+ N = O(N^2).
Reglas binarias según las mismas reglas de la biblioteca: Considera los casos en los que un conjunto de objetos binarios que dependan de las mismas reglas de la biblioteca, como cuando tienes varias reglas de prueba que prueban el mismo código de biblioteca. Digamos que, de N reglas, la mitad de las reglas son binarias y la otra mitad de la biblioteca. Ahora, considera que cada objeto binario crea una copia de alguna propiedad calculada sobre el cierre transitivo de las reglas de la biblioteca, como la ruta de clase del tiempo de ejecución de Java o la línea de comandos del vinculador de C++. Por ejemplo, podría expandir la representación de la cadena de línea de comandos de la acción de vínculo de C++. N/2 copias de N/2 elementos es memoria O(N^2).
Clases de colecciones personalizadas para evitar la complejidad cuadrática
Bazel se ve muy afectado por ambas situaciones, por lo que presentamos un conjunto de
clases de colección personalizadas que comprimen de manera eficaz la información en la memoria
evitando la copia en cada paso. Casi todas estas estructuras de datos tienen una semántica establecida, por lo que la llamamos depset (también conocida como NestedSet en la implementación interna). La mayoría de los cambios para reducir el consumo de memoria de Bazel en los últimos años fueron cambios en el uso de dependencias en lugar de lo que se usaba antes.
Por desgracia, el uso de depsets no resuelve automáticamente todos los problemas. En particular, incluso la solo iteración sobre un depset en cada regla vuelve a introducir un consumo de tiempo cuadrático. A nivel interno, NestedSets también tiene algunos métodos auxiliares para facilitar la interoperabilidad con clases de colecciones normales. Lamentablemente, pasar por accidente un NestedSet a uno de estos métodos genera un comportamiento de copia y vuelve a introducir el consumo de memoria cuadrática.