Skyframe

Informar un problema Ver código fuente Nocturno · 8.4 · 8.3 · 8.2 · 8.1 · 8.0 · 7.6

Es el modelo de evaluación paralela y de incrementalidad de Bazel.

Modelo de datos

El modelo de datos consta de los siguientes elementos:

  • SkyValue, también llamados nodos SkyValues son objetos inmutables que contienen todos los datos creados durante la compilación y las entradas de la compilación. Algunos ejemplos son los archivos de entrada, los archivos de salida, los destinos y los destinos configurados.
  • SkyKey: Es un nombre corto e inmutable para hacer referencia a un SkyValue, por ejemplo, FILECONTENTS:/tmp/foo o PACKAGE://foo.
  • SkyFunction: Compila nodos en función de sus claves y nodos dependientes.
  • Es un gráfico de nodos. Es una estructura de datos que contiene la relación de dependencia entre los nodos.
  • Skyframe: Es el nombre de código del framework de evaluación incremental en el que se basa Bazel.

Evaluación

Una compilación consiste en evaluar el nodo que representa la solicitud de compilación (este es el estado al que aspiramos, pero hay mucho código heredado en el camino). Primero, se encuentra su SkyFunction y se llama con la clave del SkyKey de nivel superior. Luego, la función solicita la evaluación de los nodos que necesita para evaluar el nodo de nivel superior, lo que, a su vez, genera otras invocaciones de funciones, y así sucesivamente, hasta que se alcanzan los nodos hoja (que suelen ser nodos que representan archivos de entrada en el sistema de archivos). Por último, obtenemos el valor de SkyValue de nivel superior, algunos efectos secundarios (como archivos de salida en el sistema de archivos) y un gráfico acíclico dirigido de las dependencias entre los nodos que participaron en la compilación.

Un SkyFunction puede solicitar SkyKeys en varios pases si no puede saber de antemano todos los nodos que necesita para hacer su trabajo. Un ejemplo simple es evaluar un nodo de archivo de entrada que resulta ser un vínculo simbólico: la función intenta leer el archivo, se da cuenta de que es un vínculo simbólico y, por lo tanto, recupera el nodo del sistema de archivos que representa el destino del vínculo simbólico. Sin embargo, ese archivo puede ser un vínculo simbólico, en cuyo caso la función original también deberá recuperar su destino.

Las funciones se representan en el código con la interfaz SkyFunction y los servicios que le proporciona una interfaz llamada SkyFunction.Environment. Estas son las acciones que pueden realizar las funciones:

  • Solicita la evaluación de otro nodo llamando a env.getValue. Si el nodo está disponible, se devuelve su valor; de lo contrario, se devuelve null y se espera que la función devuelva null. En el último caso, se evalúa el nodo dependiente y, luego, se vuelve a invocar el compilador de nodos original, pero, esta vez, la misma llamada a env.getValue devolverá un valor que no sea null.
  • Llama a env.getValues() para solicitar la evaluación de varios otros nodos. Esto hace esencialmente lo mismo, excepto que los nodos dependientes se evalúan en paralelo.
  • Realizar cálculos durante la invocación
  • Tienen efectos secundarios, por ejemplo, escribir archivos en el sistema de archivos. Se debe tener cuidado para que dos funciones diferentes no se superpongan. En general, los efectos secundarios de escritura (en los que los datos fluyen hacia afuera de Bazel) son aceptables, mientras que los efectos secundarios de lectura (en los que los datos fluyen hacia adentro de Bazel sin una dependencia registrada) no lo son, ya que son una dependencia no registrada y, como tales, pueden causar compilaciones incrementales incorrectas.

Las implementaciones de SkyFunction no deben acceder a los datos de ninguna otra manera que no sea solicitando dependencias (por ejemplo, leyendo directamente el sistema de archivos), ya que esto hace que Bazel no registre la dependencia de datos en el archivo que se leyó, lo que genera compilaciones incrementales incorrectas.

Una vez que una función tiene suficientes datos para realizar su trabajo, debe devolver un valor que no sea null para indicar que se completó.

Esta estrategia de evaluación tiene varios beneficios:

  • Hermeticidad. Si las funciones solo solicitan datos de entrada dependiendo de otros nodos, Bazel puede garantizar que, si el estado de entrada es el mismo, se devuelven los mismos datos. Si todas las funciones de cielo son determinísticas, significa que toda la compilación también será determinística.
  • Incrementabilidad correcta y perfecta Si se registran todos los datos de entrada de todas las funciones, Bazel puede invalidar solo el conjunto exacto de nodos que se deben invalidar cuando cambian los datos de entrada.
  • Paralelismo. Dado que las funciones solo pueden interactuar entre sí solicitando dependencias, las funciones que no dependen entre sí se pueden ejecutar en paralelo, y Bazel puede garantizar que el resultado sea el mismo que si se ejecutaran de forma secuencial.

Incrementalidad

Dado que las funciones solo pueden acceder a los datos de entrada si dependen de otros nodos, Bazel puede compilar un gráfico de flujo de datos completo desde los archivos de entrada hasta los archivos de salida y usar esta información para volver a compilar solo los nodos que realmente necesitan recompilarse: el cierre transitivo inverso del conjunto de archivos de entrada modificados.

En particular, existen dos estrategias posibles de incrementalidad: la ascendente y la descendente. La opción óptima depende de cómo se vea el gráfico de dependencia.

  • Durante la invalidación ascendente, después de que se compila un gráfico y se conoce el conjunto de entradas modificadas, se invalidan todos los nodos que dependen de forma transitiva de los archivos modificados. Esto es óptimo si sabemos que se volverá a compilar el mismo nodo de nivel superior. Ten en cuenta que la invalidación de abajo hacia arriba requiere que se ejecute stat() en todos los archivos de entrada de la compilación anterior para determinar si se modificaron. Esto se puede mejorar usando inotify o un mecanismo similar para obtener información sobre los archivos modificados.

  • Durante la invalidación de arriba hacia abajo, se verifica el cierre transitivo del nodo de nivel superior y solo se conservan los nodos cuyo cierre transitivo está limpio. Esto es mejor si sabemos que el gráfico de nodos actual es grande, pero solo necesitamos un pequeño subconjunto de él en la próxima compilación: la invalidación ascendente invalidaría el gráfico más grande de la primera compilación, a diferencia de la invalidación descendente, que solo recorre el gráfico pequeño de la segunda compilación.

Actualmente, solo realizamos la invalidación ascendente.

Para obtener una mayor incrementalidad, usamos la poda de cambios: Si se invalida un nodo, pero, al volver a compilarlo, se descubre que su valor nuevo es el mismo que el anterior, se “resucitan” los nodos que se invalidaron debido a un cambio en este nodo.

Esto es útil, por ejemplo, si se cambia un comentario en un archivo C++: el archivo .o generado a partir de él será el mismo, por lo que no es necesario volver a llamar al vinculador.

Vinculación y compilación incrementales

La principal limitación de este modelo es que la invalidación de un nodo es un asunto de todo o nada: cuando cambia una dependencia, el nodo dependiente siempre se vuelve a compilar desde cero, incluso si existiera un mejor algoritmo que mutara el valor anterior del nodo en función de los cambios. Estos son algunos ejemplos en los que sería útil:

  • Vinculación incremental
  • Cuando cambia un solo archivo .class en un .jar, teóricamente podríamos modificar el archivo .jar en lugar de volver a compilarlo desde cero.

Actualmente, Bazel no admite estas funciones de forma fundamentada (tenemos cierto nivel de compatibilidad con la vinculación incremental, pero no se implementó en Skyframe) por dos motivos: solo obtuvimos ganancias de rendimiento limitadas y era difícil garantizar que el resultado de la mutación fuera el mismo que el de una recompilación limpia, y Google valora las compilaciones que son repetibles bit por bit.

Hasta ahora, siempre podíamos lograr un rendimiento lo suficientemente bueno simplemente descomponiendo un paso de compilación costoso y logrando una reevaluación parcial de esa manera: dividía todas las clases de una app en varios grupos y realizaba el proceso de dexing en ellos por separado. De esta manera, si las clases de un grupo no cambian, no es necesario volver a realizar el proceso de dexing.

Asignación a conceptos de Bazel

A continuación, se incluye una descripción general aproximada de algunas de las implementaciones de SkyFunction que Bazel usa para realizar una compilación:

  • FileStateValue. Es el resultado de un lstat(). En el caso de los archivos existentes, también calculamos información adicional para detectar cambios en el archivo. Este es el nodo de nivel más bajo en el gráfico de Skyframe y no tiene dependencias.
  • FileValue. Se usa para cualquier elemento que se preocupe por el contenido real o la ruta resuelta de un archivo. Depende del FileStateValue correspondiente y de los vínculos simbólicos que deban resolverse (por ejemplo, el FileValue para a/b necesita la ruta resuelta de a y la ruta resuelta de a/b). La distinción entre FileStateValue es importante porque, en algunos casos (por ejemplo, cuando se evalúan globs del sistema de archivos, como srcs=glob(["*/*.java"])), no se necesita el contenido del archivo.
  • DirectoryListingValue. Esencialmente, el resultado de readdir(). Depende del FileValue asociado al directorio.
  • PackageValue. Representa la versión analizada de un archivo BUILD. Depende del FileValue del archivo BUILD asociado y, también, de forma transitiva, de cualquier DirectoryListingValue que se use para resolver los comodines en el paquete (la estructura de datos que representa el contenido de un archivo BUILD de forma interna).
  • ConfiguredTargetValue. Representa un destino configurado, que es una tupla del conjunto de acciones generadas durante el análisis de un destino y la información proporcionada a los destinos configurados que dependen de este. Depende del PackageValue en el que se encuentra el destino correspondiente, el ConfiguredTargetValues de las dependencias directas y un nodo especial que representa la configuración de la compilación.
  • ArtifactValue. Representa un archivo en la compilación, ya sea un artefacto de origen o de salida (los artefactos son casi equivalentes a los archivos y se usan para hacer referencia a los archivos durante la ejecución real de los pasos de compilación). En el caso de los archivos fuente, depende del FileValue del nodo asociado. En el caso de los artefactos de salida, depende del ActionExecutionValue de la acción que genera el artefacto.
  • ActionExecutionValue. Representa la ejecución de una acción. Depende del ArtifactValues de sus archivos de entrada. La acción que ejecuta actualmente se encuentra dentro de su clave de cielo, lo que contradice el concepto de que las claves de cielo deben ser pequeñas. Estamos trabajando para resolver esta discrepancia (ten en cuenta que ActionExecutionValue y ArtifactValue no se usan si no ejecutamos la fase de ejecución en Skyframe).