Resumo Técnico: JEDI – Avaliação Java de Consultas Declarativas e Imperativas

Declaração do Problema

A API Stream do Java, introduzida no Java 8, oferece uma sintaxe declarativa para processamento de coleções e fontes de dados infinitas, visando melhorar a produtividade do desenvolvedor, a legibilidade do código e a manutenibilidade em comparação com o código tradicional baseado em loops imperativos. Embora a API simplifique a computação paralela por meio de abstrações de alto nível, a literatura existente indica que implementações baseadas em Stream frequentemente sofrem penalidades de desempenho em relação a códigos imperativos equivalentes.

Uma lacuna crítica identificada neste trabalho é a falta de suites de benchmark dedicadas à API Stream. Sem tais benchmarks, é difícil para:

1. Pesquisadores e Desenvolvedores de Bibliotecas: Otimizar a implementação da API Stream dentro da Biblioteca de Classes do Java (JCL).
2. Desenvolvedores de Aplicações: Compreender as características de desempenho de diferentes operações de stream e estratégias de paralelização para escrever código eficiente.

Os benchmarks atuais ou não visam explicitamente a API Stream ou dependem de pipelines sintéticos simples que não refletem cargas de trabalho complexas de processamento de dados do mundo real.

Metodologia

Para abordar essa lacuna, os autores apresentam o JEDI (Avaliação Java de Consultas Declarativas e Imperativas), uma suite de benchmarks gerada automaticamente pela conversão de consultas SQL em código-fonte Java.

Processo de Geração

1. Material de Origem: Os autores utilizam o benchmark TPC-H, um benchmark amplamente usado de análise de dados composto por consultas complexas que cobrem várias funcionalidades de processamento de dados (junções, agregações, filtragem, ordenação).
2. Conversão de Código: Os autores estenderam uma ferramenta existente, S2S (SQL para Stream), para converter consultas SQL em múltiplas implementações Java semanticamente equivalentes.
   • Mapeamento de Esquema: Tabelas SQL são mapeadas para arrays na memória de objetos.
   • Tradução de Consultas:
     • Projeções SELECT $\rightarrow$ map(...)
     • Predicados WHERE $\rightarrow$ filter(...)
     • ORDER BY $\rightarrow$ sorted(...)
     • LIMIT $\rightarrow$ limit(...)
     • GROUP BY e Agregações $\rightarrow$ collect(...) com coletores gerados.
     • JOIN $\rightarrow$ Implementado via flatMap (construindo um hash-map para o lado de construção) ou mapMulti.
3. Variantes de Implementação: Para uma única consulta SQL, o JEDI gera múltiplas variantes para comparar diferentes padrões de codificação e estratégias de execução:
   • Variantes Sequenciais:
     • O1 (Fusão de Filtros): Combinar múltiplos predicados em uma única chamada filter versus múltiplas chamadas encadeadas.
     • O2 (Implementação de Junção): Usar mapMulti versus flatMap para operações de junção.
   • Variantes Paralelas (O3):
     • P: Streams paralelos ordenados (parallel()).
     • PU: Streams paralelos não ordenados (parallel().unordered()).
     • CG: Streams paralelos não ordenados usando groupingByConcurrent (estado compartilhado com sincronização baseada em bloqueio).
     • CGCC: CG com coletores a jusante seguros para thread (operações atômicas sem bloqueio).
   • Base Imperativa: Uma implementação baseada em loops usando exatamente as mesmas estruturas de dados e ordem de operações que as versões de stream para medir o "sobrecarga da API Stream".

Configuração de Avaliação

• Hardware: Duas arquiteturas distintas: Intel Xeon Gold (16 núcleos) e ARM Neoverse-N1 (80 núcleos).
• JVMs: Oracle JDK 24 e GraalVM 24.
• Conjuntos de Dados: Fatores de escala TPC-H de 1 (1GB) para análise sequencial e 10 (10GB) para análise paralela.
• Ferramentas: Java Microbenchmark Harness (JMH) com iterações de aquecimento e medidas para garantir desempenho em estado estacionário.

Principais Contribuições

1. Suite de Benchmark JEDI: O lançamento de uma suite de benchmarks de código aberto derivada do TPC-H, gerando automaticamente implementações de stream e imperativas semanticamente equivalentes.
2. Gerador de Código: Uma versão estendida do S2S que suporta múltiplas estratégias de implementação (otimizações sequenciais e vários padrões de redução paralela).
3. Diretrizes de Desempenho: Um conjunto de melhores práticas derivadas para usar a API Stream eficientemente com base em dados empíricos.
4. Análise de Sobrecarga: Uma comparação direta de código baseado em stream versus código imperativo usando estruturas de dados idênticas e ordens de operação para isolar o custo de desempenho das abstrações da API.

Resultados e Descobertas

RQ1: Otimizações Sequenciais (Fusão de Filtros e Implementação de Junção)

• Fusão de Filtros (O1): Combinar predicados em uma única chamada filter melhora o desempenho, particularmente quando muitos predicados estão presentes (por exemplo, aceleração de 3,54x em um microbenchmark com 7 predicados).
• Implementação de Junção (O2): Usar mapMulti em vez de flatMap para junções produz melhorias significativas (aceleração geométrica média de 1,38x no JDK Intel).
• Conclusão: Os desenvolvedores devem aplicar tanto O1 quanto O2 sempre que possível.

RQ2: Estratégias de Paralelização

• Sem Vencedor Universal: Nenhuma estratégia paralela única domina todos os cenários. O desempenho depende fortemente das características dos dados, especificamente do número de grupos agregados e da natureza da agregação.
• Agregações Escalares vs. Agrupadas:
  • Para agregações escalares (sem agrupamento) ou pequenos números de grupos, streams paralelos ordenados (P) ou não ordenados (PU) superam estratégias de estado compartilhado (CG, CGCC) devido à menor contenção.
  • Para agregações agrupadas com muitos grupos, CG (usando groupingByConcurrent) é geralmente a melhor estratégia. À medida que o número de grupos aumenta, a contenção de bloqueio diminui, tornando a sincronização baseada em bloqueio eficiente.
• Sem Bloqueio vs. Com Bloqueio: CGCC (sem bloqueio) não supera consistentemente CG (com bloqueio) e introduz complexidade de implementação. No entanto, CGCC é mais robusto para contagens de grupos muito pequenas onde CG sofre de alta contenção.
• Operações Distintas: Embora streams não ordenados (PU) sejam geralmente recomendados para distinct, o estudo descobriu que, para streams com um baixo número de elementos distintos, streams paralelos ordenados (P) podem ser até 2x mais rápidos devido à sobrecarga de gerenciar um ConcurrentHashMap compartilhado em streams não ordenados.

RQ3: Desempenho Stream vs. Imperativo

• Superioridade Imperativa: Código imperativo baseado em loops supera consistentemente o código baseado em stream.
• Magnitude: A aceleração geométrica média do código imperativo sobre a melhor implementação sequencial de stream varia de 1,28x a 1,41x entre diferentes JVMs e arquiteturas.
• Contexto: Embora isso confirme descobertas anteriores, os autores observam que a lacuna é menor do que em alguns estudos anteriores, sugerindo melhorias na implementação da API Stream ao longo do tempo. No entanto, para código crítico em termos de desempenho, o código imperativo permanece substancialmente mais rápido.

RQ4: Complexidade do Código

• Legibilidade: Apesar da lacuna de desempenho, o código baseado em stream exibe métricas de complexidade significativamente menores.
• Métricas: A complexidade cognitiva do código de stream base é 2,43x menor que a do código imperativo. Mesmo com otimizações (O1+O2), o código de stream permanece 1,62x menos complexo que o código imperativo.
• Compromisso: Otimizar o código de stream (por exemplo, fundindo filtros) aumenta suas métricas de complexidade, mas mantém abaixo da complexidade dos equivalentes imperativos.

Significado e Alegações

O artigo posiciona o JEDI como uma ferramenta vital tanto para a comunidade Java quanto para os implementadores da JVM:

• Para Desenvolvedores: Fornece diretrizes orientadas por dados para minimizar a sobrecarga de desempenho da API Stream, sugerindo padrões específicos (por exemplo, mapMulti, groupingByConcurrent para grandes grupos) com base nas características da carga de trabalho.
• Para Implementadores de Bibliotecas: A suite de benchmarks e a "sobrecarga" identificada fornecem uma linha de base para otimizar a implementação da API Stream a fim de fechar a lacuna de desempenho com o código imperativo.
• Para Pesquisadores: Oferece uma carga de trabalho complexa e reproduzível (derivada do TPC-H) para avaliar futuras otimizações, ferramentas de refatoração ou estratégias de paralelização.

Os autores reconhecem modestamente limitações, observando que o JEDI atualmente foca em fontes de dados baseadas em arrays e padrões específicos de tradução SQL-para-Stream. Eles planejam estender o gerador para cobrir mais métodos da API Stream e variar fontes de dados (por exemplo, Listas, Conjuntos) em trabalhos futuros.