Resumo Técnico: OxyMake

Problema

Motores de fluxo de trabalho (workflows) na categoria "Make lineage" (ex: GNU Make, Snakemake, Nextflow) dependem historicamente do tempo de modificação do arquivo (mtime) como um proxy para detectar mudanças de conteúdo. O artigo argumenta que isso é um "proxy vazado" (leaky proxy) que falha de duas maneiras críticas:

1. Reexecuções Fantasmas: Operações como git checkout, cópias de árvores ou restaurações de backup reescrevem o mtime sem alterar o conteúdo do arquivo, forçando a reexecução desnecessária.
2. Reuso Obsoleto: Por outro lado, se o conteúdo de um arquivo de saída estiver obsoleto, mas seu mtime parecer mais recente que o de seus inputs (devido a desvio de relógio ou restauração), o motor reutiliza silenciosamente a saída incorreta.

Embora o Snakemake 7 mitigue reexecuções fantasmas registrando a procedência por saída (código, parâmetros, conjunto de inputs), esse registro está vinculado a uma única árvore de trabalho. Ele não pode viajar entre máquinas, caches compartilhados ou detectar corrupção em disco onde os bytes mudam sem atualizações de metadados.

Metodologia

O OxyMake é um motor de workflow em Rust, de binário único, que substitui o proxy mtime por cache endereçável por conteúdo.

Princípios de Design Principais

1. Chaves Endereçáveis por Conteúdo: A chave de cache para um job é um hash BLAKE3 da origem da regra, hashes de conteúdo dos inputs, parâmetros, especificação do ambiente e plataforma. Esta chave é uma função pura dos inputs declarados.
2. Arquitetura de Três Grafos:
   • RuleGraph (Lógico): Regras abstratas com wildcards não resolvidos.
   • JobGraph (Físico): DAG totalmente resolvido e otimizado com jobs concretos.
   • ExecGraph (Tempo de Execução): Anotado com estado vivo, métricas e logs.
3. TOML Declarativo: Os workflows são definidos em TOML, garantindo parseabilidade estática e evitando o overhead de execução dinâmica de DSLs em Python (como o Snakemake).
4. Execução Sem Daemon: O motor opera sem um daemon central. Utiliza um protocolo cooperativo de reivindicação/reivindicação (claim/reclaim) para sessões concorrentes, onde o estado é persistido em um banco de dados SQLite local (.oxymake/state.db).
5. Especificação Formal: Invariantes de segurança entre sessões (ex: impedir que duas sessões reivindiquem o mesmo job) são especificadas em TLA+ e verificadas via model-checking com o verificador de modelo TLC. Isso aborda a classe de perigo "Transições de Estado Concorrentes Entre Pares Falhando Independentemente" (CSTAFP).

Modelo de Execução

O OxyMake suporta um espectro de modos de execução:

• Shell/Run/Script: I/O padrão baseado em arquivos.
• Call: Referências de funções puras (ex: funções Python) onde o OxyMake gerencia o I/O, permitindo a passagem de dados em memória entre jobs em executores suportados (ex: Ray).

O motor é "convergente": ox run garante que as saídas existam em vez de apenas lançar jobs. Ele lida com invalidação transitiva; se um arquivo intermediário for deletado, o pré-scan do cache detecta a ausência e dispara a reconstrução de todos os jobs dependentes a jusante.

Principais Contribuições

O artigo lista sete contribuições específicas:

1. Cache Endereçável por Conteúdo: Elimina reexecuções fantasmas para inputs declarados e suporta cascata transitiva em caso de deleção. Inclui um caminho rápido mtime+hash para performance.
2. Implementação em Rust: Um binário único estaticamente vinculado (14,9 MB) com um resolvedor de encadeamento reverso (backward-chaining) por meio de busca de padrões pré-compilados, alcançando resolução de DAG em sub-segundos.
3. Concorrência Formalmente Especificada: Invariantes de segurança entre sessões são especificadas em TLA+ e verificadas via model-checking, em vez de depender apenas de testes.
4. Arquitetura de Três Grafos: Separa a definição de regras, planos resolvidos e traços de execução, alinhando-se aos princípios FAIR (Findable, Accessible, Interoperable, Reusable).
5. Lockfile de Reprodutibilidade (ox.lock): Um registro de plano baseado em hash de conteúdo que permite a re-derivação exata de grafos de jobs anos depois.
6. Interface Legível por Máquina: Fluxos de eventos estruturados em NDJSON e aprovação de portão programática para integração com ferramentas downstream.
7. Execução Poliglota: Suporta modos shell, chamadas in-process e scripts com capacidades de passagem de dados em memória.

Resultados e Avaliação

Experimentos foram conduzidos em um Apple M4 Max (16 núcleos, 128 GB de RAM).

• Velocidade de Resolução de DAG: O OxyMake resolve um DAG de 10.000 jobs em 69 ms, comparado ao Snakemake 7.32.4 que levou 2,31 s (um ganho de velocidade de 33,3×). Isso é atribuído aos padrões regex pré-compilados e à ausência de overhead do interpretador Python.
• Performance de Cold End-to-End: Em uma execução a frio (primeira execução), o OxyMake é mais lento (1,25–2,3×) que o Snakemake. O artigo atribui isso ao custo de realizar o hashing dos inputs e escrever nos stores endereçáveis por conteúdo.
• Performance de Warm Re-run: Em reexecuções de cache quente (warm-cache re-runs/no-op rebuilds), o OxyMake é 7,54× mais rápido que o Snakemake (372 ms vs 2,81 s para 10.000 jobs). Mesmo com verificação total de conteúdo (--cache-validation=hash), ele permanece 4,02× mais rápido.
• Robustez de Endereçamento por Conteúdo: Em um teste de "git checkout" onde o mtime foi perturbado mas o conteúdo permaneceu idêntico:
  • O Snakemake 7.32.4 reexecutou 0 jobs (devido aos seus registros de procedência).
  • O OxyMake, com seu padrão anterior de puro mtime, reexecutou 6.667 jobs (o raio completo a jusante).
  • O OxyMake atual, com seu padrão mtime+hash e modo hash, reexecutou 0 jobs.
• Escalabilidade: O tempo de resolução escala quase linearmente com a contagem de jobs (aprox. 6,6 µs/job adicionado a cada aumento de 100x no número de jobs).
• Pegada de Memória: O pico de memória do orquestrador do OxyMake (90,7 MiB) é 2,04× menor que o do Snakemake (184,7 MiB) em execuções grandes.

Significância e Alegações

O artigo posiciona o OxyMake como uma evolução rigorosa do paradigma Make, priorizando a corretude e a reprodutibilidade sobre a velocidade bruta de execução a frio.

• Corretude sobre Heurísticas: Ao substituir o mtime pelo hashing de conteúdo, o OxyMake garante que a decisão de cache seja uma função pura dos inputs declarados, sobrevivendo à volatilidade do sistema de arquivos e permitindo a portabilidade do cache entre máquinas da mesma plataforma.
• Rigor Formal: O uso de TLA+ para especificar e verificar modelos de invariantes de segurança entre sessões é uma característica distintiva, abordando perigos de concorrência que apenas testes não conseguiriam cobrir.
• Conformidade FAIR: O OxyMake visa explicitamente as camadas de "Orquestração" (L2) e "Traço de Execução" (L3/L4) da escada de reprodutibilidade FAIR, delegando o "Substrato" (L1) para gerenciadores de pacotes externos (ex: Guix, Nix) em vez de tentar absorver esse contrato.
• Trade-offs Honestos: Os autores reconhecem explicitamente que o registro de endereçamento por conteúdo impõe uma penalidade em execuções a frio. O motor troca o throughput inicial bruto pela capacidade de servir reexecuções de cache de forma eficiente e fornecer decisões de reconstrução auditáveis e portáteis.

O artigo conclui que o OxyMake é um "motor de workflow em Rust de binário único" que combina com sucesso o paradigma de encadeamento reverso com engenharia moderna, ofereando uma alternativa determinística e de alta performance para workflows científicos onde a reprodutibilidade e a portabilidade de cache são primordiais.