Skyframe

Informar un problemaopen_in_new Ver fuenteopen_in_new

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

Modelo de datos

El modelo de datos consta de los siguientes elementos:

• SkyValue. También se denomina nodos. Las SkyValues son objetos inmutables que contienen todos los datos compilados durante la compilación y las entradas de esta. Algunos ejemplos son los archivos de entrada, los archivos de salida, los objetivos y los objetivos configurados.
• SkyKey: Es un nombre inmutable corto para hacer referencia a un SkyValue, por ejemplo, FILECONTENTS:/tmp/foo o PACKAGE://foo.
• SkyFunction. Compila nodos según sus claves y nodos dependientes.
• 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 se logra evaluando el nodo que representa la solicitud de compilación.

Primero, Bazel encuentra el SkyFunction correspondiente a 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 llamadas a SkyFunction, hasta que se alcanzan los nodos hoja. Los nodos hoja suelen ser los que representan archivos de entrada en el sistema de archivos. Por último, Bazel obtiene el valor de SkyValue de nivel superior, algunos efectos secundarios (como los archivos de salida en el sistema de archivos) y un grafo acíclico dirigido de las dependencias entre los nodos involucrados en la compilación.

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

La interfaz SkyFunction representa las funciones en el código y los servicios que le proporciona una interfaz llamada SkyFunction.Environment. Estas son las acciones que pueden realizar las funciones:

• Llama a env.getValue para solicitar la evaluación de otro nodo. Si el nodo está disponible, se muestra su valor; de lo contrario, se muestra null y se espera que la función en sí muestre 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 mostrará un valor que no es null.
• Llama a env.getValues() para solicitar la evaluación de muchos otros nodos. Esto hace lo mismo, excepto que los nodos dependientes se evalúan en paralelo.
• Realizar cálculos durante la invocación
• Tener efectos secundarios, como escribir archivos en el sistema de archivos Se debe tener cuidado de que dos funciones diferentes eviten pisarse sobre la otra. En general, los efectos secundarios de escritura (en los que los datos fluyen hacia afuera de Bazel) están bien, los efectos secundarios de lectura (donde los datos fluyen hacia Bazel sin una dependencia registrada) no lo son, porque son una dependencia no registrada y, por lo tanto, pueden causar compilaciones incrementales incorrectas.

Las implementaciones de SkyFunction con buen comportamiento evitan acceder a los datos de otra manera que no sea solicitar dependencias (como leer directamente el sistema de archivos), ya que eso 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 tenga suficientes datos para realizar su trabajo, debe mostrar un valor que no sea null que indique la finalización.

Esta estrategia de evaluación tiene una serie de beneficios:

• Hermética. 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 mostrarán los mismos datos. Si todas las funciones sky son deterministas, esto significa que toda la compilación también será determinística.
• Incrementalidad 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í mediante la solicitud de 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 según otros nodos, Bazel puede crear 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 en realidad deben recompilar: el cierre transitivo inverso del conjunto de archivos de entrada modificados.

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

• Durante la invalidación ascendente, después de que se compila un grafo y se conoce el conjunto de entradas modificadas, se invalidan todos los nodos que dependen de manera transitiva de los archivos modificados. Esto es óptimo si se vuelve a compilar el mismo nodo de nivel superior. Ten en cuenta que la invalidación ascendente requiere que se ejecute stat() en todos los archivos de entrada de la compilación anterior para determinar si se cambiaron. 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 el gráfico de nodos es grande, pero la siguiente compilación solo necesita un pequeño subconjunto: la invalidación ascendente invalidaría el grafo más grande de la primera compilación, a diferencia de la invalidación de arriba abajo, que solo recorre el gráfico pequeño de la segunda compilación.

Bazel solo hace la invalidación de abajo hacia arriba.

Para obtener más incrementalidad, Bazel usa la reducción de cambios: si se invalida un nodo, pero después de volver a compilarlo, se descubre que su valor nuevo es el mismo que su valor anterior y se “resucitan” los nodos que se invalidaron debido a un cambio en él.

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

Vinculación o 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 esto podría ser útil:

• Vinculación incremental
• Cuando un solo archivo de clase cambia en un archivo JAR, es posible modificar el archivo JAR in situ en lugar de volver a compilarlo desde cero.

La razón por la que Bazel no admite estas funciones de principio a fin es doble:

• Hubo mejoras en el rendimiento limitadas.
• La dificultad para validar que el resultado de la mutación es el mismo que el de una recompilación limpia y Google valora las compilaciones que se pueden repetir bit a bit.

Hasta ahora, era posible lograr un rendimiento lo suficientemente bueno con el descomposición de un paso de compilación costoso y la realización de una reevaluación parcial de esa manera. Por ejemplo, en una app para Android, puedes dividir todas las clases en varios grupos y convertirlas en DEX por separado. De esta manera, si las clases de un grupo no se modifican, no es necesario rehacer la conversión a dex.

Asigna a conceptos de Bazel

Este es un resumen de alto nivel de las implementaciones clave de SkyFunction y SkyValue que Bazel usa para realizar una compilación:

• FileStateValue Es el resultado de un elemento lstat(). En el caso de los archivos existentes, la función también procesa información adicional con el fin de detectar cambios en el archivo. Este es el nodo de nivel más bajo del gráfico de Skyframe y no tiene dependencias.
• FileValue Lo usa todo lo que se preocupe por el contenido real o la ruta de acceso resuelta de un archivo. Depende del FileStateValue correspondiente y de cualquier symlink que se deban resolver (como FileValue para a/b, necesita la ruta de acceso resuelta de a y la ruta de acceso resuelta de a/b). La distinción entre FileValue y FileStateValue es importante porque esta última se puede usar en casos en los que el contenido del archivo no sea realmente necesario. Por ejemplo, el contenido del archivo es irrelevante cuando se evalúan los globs del sistema de archivos (como srcs=glob(["*/*.java"])).
• DirectoryListingStateValue Es el resultado de readdir(). Al igual que FileStateValue, este es el nodo de nivel más bajo y no tiene dependencias.
• DirectoryListingValue. Lo usa todo lo que se preocupe por las entradas de un directorio. Depende del DirectoryListingStateValue correspondiente y del FileValue asociado del 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 globs en el paquete (la estructura de datos que representa internamente el contenido de un archivo BUILD).
• ConfiguredTargetValue Representa un destino configurado, que es una tupla del conjunto de acciones generadas durante el análisis de un objetivo y la información proporcionada a destinos configurados dependientes. Depende de la PackageValue en la que se encuentra el destino correspondiente, del ConfiguredTargetValues de las dependencias directas y de un nodo especial que representa la configuración de compilación.
• ArtifactValue Representa un archivo en la compilación, ya sea una fuente o un artefacto de salida. Los artefactos son casi equivalentes a los archivos y se usan para hacer referencia a ellos durante la ejecución real de los pasos de compilación. Los archivos de origen dependen del FileValue del nodo asociado, y los artefactos de salida dependen del ActionExecutionValue de cualquier acción que genere el artefacto.
• ActionExecutionValue. Representa la ejecución de una acción. Depende de ArtifactValues de sus archivos de entrada. La acción que ejecuta está contenida dentro de su SkyKey, lo que es contrario al concepto de que las SkyKeys deben ser pequeñas. Ten en cuenta que ActionExecutionValue y ArtifactValue no se usan si no se ejecuta la fase de ejecución.

Como ayuda visual, en este diagrama, se muestran las relaciones entre las implementaciones de SkyFunction después de una compilación de Bazel: