Skyframe

<ph-0-0> open_in_newopen_in_newopen_in_new

O modelo de avaliação paralela e incrementabilidade do Bazel.

Modelo de dados

O modelo de dados consiste nos seguintes itens:

• SkyValue. Também chamados de nós. SkyValues são objetos imutáveis que contêm todos os dados criados durante o build e as entradas dele. Exemplos: arquivos de entrada, arquivos de saída e destinos configurados.
• SkyKey: um nome curto e imutável para se referir a um SkyValue, por exemplo, FILECONTENTS:/tmp/foo ou PACKAGE://foo.
• SkyFunction. Cria nós com base em suas chaves e nós dependentes.
• Gráfico de nós. Uma estrutura de dados contendo a relação de dependência entre os nós.
• Skyframe. Codinome do framework de avaliação incremental em que o Bazel é baseado.

Avaliação

Um build é alcançado avaliando o nó que representa a solicitação de build.

Primeiro, o Bazel encontra o SkyFunction correspondente à chave do SkyKey de nível superior. Em seguida, a função solicita a avaliação dos nós necessários para avaliar o nó de nível superior, que, por sua vez, resultam em outras chamadas SkyFunction, até que os nós da folha sejam alcançados. Os nós folha geralmente são aqueles que representam arquivos de entrada no sistema de arquivos. Por fim, o Bazel acaba com o valor de SkyValue de nível superior, alguns efeitos colaterais (como arquivos de saída no sistema de arquivos) e um gráfico acíclico dirigido das dependências entre os nós envolvidos no build.

Um SkyFunction pode solicitar SkyKeys em vários cartões se não puder dizer com antecedência todos os nós de que precisa para realizar o trabalho. Um exemplo simples é avaliar um nó de arquivo de entrada que acaba sendo um link simbólico: a função tenta ler o arquivo, percebe que é um link simbólico e busca o nó do sistema de arquivos que representa o destino do link simbólico. No entanto, ele pode ser um link simbólico. Nesse caso, a função original também precisará buscar o destino.

As funções são representadas no código pela interface SkyFunction e os serviços fornecidos a ela por uma interface chamada SkyFunction.Environment. Estas são as coisas que as funções podem fazer:

• Solicite a avaliação de outro nó chamando env.getValue. Se o nó estiver disponível, o valor dele será retornado. Caso contrário, null será retornado e a própria função retornará null. No último caso, o nó dependente é avaliado e, em seguida, o builder de nós original é invocado novamente, mas, desta vez, a mesma chamada env.getValue retorna um valor diferente de null.
• Solicite a avaliação de vários outros nós chamando env.getValues(). Esse processo é essencialmente o mesmo, mas os nós dependentes são avaliados em paralelo.
• Fazer cálculos durante a invocação
• Têm efeitos colaterais, como a gravação de arquivos no sistema de arquivos. É preciso ter cuidado para que duas funções diferentes evitem pisar uma na outra. Em geral, não há problemas com os efeitos colaterais de gravação, em que os dados fluem para fora do Bazel, mas os efeitos colaterais de leitura (quando os dados fluem para dentro do Bazel sem uma dependência registrada), porque são uma dependência não registrada e, por isso, podem causar builds incrementais incorretos.

As implementações de SkyFunction bem comportadas evitam acessar dados de outra maneira que não a solicitação de dependências, por exemplo, lendo diretamente o sistema de arquivos, porque isso faz com que o Bazel não registre a dependência de dados no arquivo que foi lido, resultando em builds incrementais incorretos.

Quando uma função tiver dados suficientes para fazer seu trabalho, ela retornará um valor diferente de null, indicando a conclusão.

Essa estratégia de avaliação tem vários benefícios:

• Hermeticidade. Se as funções solicitarem dados de entrada apenas dependendo de outros nós, o Bazel poderá garantir que, se o estado de entrada for o mesmo, os mesmos dados serão retornados. Se todas as funções do céu forem determinísticas, o build também será determinístico.
• Incrementabilidade correta e perfeita. Se todos os dados de entrada de todas as funções forem gravados, o Bazel poderá invalidar apenas o conjunto exato de nós que precisa ser invalidado quando os dados de entrada forem alterados.
• Paralelismo. Como as funções só podem interagir entre si por meio da solicitação de dependências, as funções que não dependem umas das outras podem ser executadas em paralelo, e o Bazel pode garantir que o resultado seja o mesmo que seria executado em sequência.

Incrementabilidade

Como as funções só podem acessar dados de entrada dependendo de outros nós, o Bazel pode criar um gráfico de fluxo de dados completo dos arquivos de entrada para os arquivos de saída e usar essas informações para recriar apenas os nós que realmente precisam ser recriados: o fechamento transitivo reverso do conjunto de arquivos de entrada alterados.

Existem duas estratégias de incrementabilidade possíveis: a de baixo para cima e a de cima para baixo. Qual deles é o ideal depende da aparência do gráfico de dependências.

• Durante a invalidação de baixo para cima, depois que um gráfico é criado e o conjunto de entradas alteradas é conhecido, todos os nós são invalidados e dependem transitivamente de arquivos alterados. Isso é ideal quando o mesmo nó de nível superior é recriado. A invalidação de baixo para cima requer a execução de stat() em todos os arquivos de entrada do build anterior para determinar se eles foram mudados. Isso pode ser melhorado usando inotify ou um mecanismo semelhante para aprender sobre os arquivos alterados.

• Durante a invalidação de cima para baixo, o fechamento transitivo do nó de nível superior é verificado e apenas os nós com fechamento transitivo limpo são mantidos. Isso é melhor se o gráfico do nó for grande, mas o próximo build precisa apenas de um pequeno subconjunto dele: a invalidação de baixo para cima invalidaria o gráfico maior do primeiro build, ao contrário da invalidação de cima para baixo, que apenas analisa o gráfico pequeno do segundo build.

O Bazel só faz a invalidação de baixo para cima.

Para ter mais incrementabilidade, o Bazel usa a remoção de mudanças: se um nó é invalidado, mas, após a recriação, é descoberto que o novo valor é igual ao antigo, os nós que foram invalidados devido a uma mudança nesse nó são "restabelecidos".

Isso é útil, por exemplo, se alguém mudar um comentário em um arquivo C++: o arquivo .o gerado a partir dele será o mesmo. Portanto, não será necessário chamar o vinculador novamente.

Compilação / vinculação incremental

A principal limitação desse modelo é que a invalidação de um nó é um caso de tudo ou nada: quando uma dependência muda, o nó dependente é sempre recriado do zero, mesmo que exista um algoritmo melhor que modifique o valor antigo do nó com base nas alterações. Veja alguns exemplos em que isso seria útil:

• Vinculação incremental
• Quando um único arquivo de classe muda em um arquivo JAR, é possível modificar o arquivo JAR no local em vez de criá-lo do zero novamente.

Há dois motivos possíveis para o Bazel não oferecer suporte a esses elementos de uma forma de princípios:

• Houve ganhos de performance limitados.
• Dificuldade para validar se o resultado da mutação é o mesmo de uma recompilação limpa, e os valores do Google são repetíveis bit a bit.

Até agora, era possível alcançar um desempenho bom o suficiente decompor uma etapa de build cara e conseguir uma reavaliação parcial dessa maneira. Por exemplo, em um app Android, você pode dividir todas as classes em vários grupos e dexá-las separadamente. Dessa forma, se as classes de um grupo não forem alteradas, a dexação não precisará ser refeita.

Como mapear para conceitos do Bazel

Este é um resumo de alto nível das principais implementações de SkyFunction e SkyValue que o Bazel usa para executar um build:

• FileStateValue de valor. O resultado de um lstat(). Para arquivos existentes, a função também calcula mais informações para detectar alterações no arquivo. Esse é o nó de nível mais baixo no gráfico do Skyframe e não tem dependências.
• FileValue. Usado por qualquer coisa que se importe com o conteúdo real ou o caminho resolvido de um arquivo. Depende do FileStateValue correspondente e de quaisquer links simbólicos que precisem ser resolvidos (como o FileValue para a/b precisa do caminho resolvido de a e o caminho resolvido de a/b). A distinção entre FileValue e FileStateValue é importante porque o último pode ser usado nos casos em que o conteúdo do arquivo não é realmente necessário. Por exemplo, o conteúdo do arquivo é irrelevante ao avaliar globs do sistema de arquivos (como srcs=glob(["*/*.java"])).
• DirectoryListingStateValue associado. Resultado de readdir(). Como FileStateValue, esse é o nó de nível mais baixo e não tem dependências.
• DirectoryListingValue associado. Usado por qualquer item que se interesse nas entradas de um diretório. Depende do DirectoryListingStateValue correspondente, bem como do FileValue associado do diretório.
• PackageValue para código. Representa a versão analisada de um arquivo BUILD. Depende do FileValue do arquivo BUILD associado e também transitivamente de qualquer DirectoryListingValue usado para resolver os globs no pacote (a estrutura de dados que representa o conteúdo de um arquivo BUILD internamente).
• ConfiguredTargetValue. Representa um destino configurado, que é uma tupla do conjunto de ações geradas durante a análise de um destino e informações fornecidas a destinos dependentes configurados. Depende do PackageValue em que o destino correspondente está, do ConfiguredTargetValues das dependências diretas e de um nó especial que representa a configuração do build.
• ArtifactValue. Representa um arquivo no build, seja ele uma origem ou um artefato de saída. Os artefatos são quase equivalentes aos arquivos e são usados para se referir a arquivos durante a execução real das etapas de build. Os arquivos de origem dependem do FileValue do nó associado, e os artefatos de saída dependem do ActionExecutionValue de qualquer ação que gere o artefato.
• ActionExecutionValue (em inglês). Representa a execução de uma ação. Depende do ArtifactValues dos arquivos de entrada. A ação executada fica contida na SkyKey, o que é contrário ao conceito de que as SkyKeys precisam ser pequenas. Observe que ActionExecutionValue e ArtifactValue não serão usados se a fase de execução não for executada.

Como auxílio visual, este diagrama mostra as relações entre as implementações da SkyFunction após uma compilação do próprio Bazel: