Projeto Leyden atrasa o compilador OpenJDK AOT e otimiza o compilador JIT em vez disso

O objetivo do Projeto Leyden é "resolver os pontos problemáticos de longo prazo do tempo de inicialização lenta do Java, do tempo lento para o desempenho máximo". Ele queria chegar lá "introduzindo um conceito de imagens estáticas" no OpenJDK. Imagens estáticas resultam da compilação Ahead-of-Time (AOT) para executáveis ​​nativos . Após dois anos sem atividade publicamente visível, o Projeto Leyden mudou em maio de 2022 para primeiro otimizar a compilação Just-in-Time (JIT). As " otimizações resultantes quase certamente serão mais fracas " do que o planejado inicialmente e alcançarão os principais desenvolvedores Java no final de 2025, no mínimo. O projeto Graal da Oracle já atingiu o objetivo do Projeto Leyden, mas a um custo que o projeto quer evitar por enquanto.

O projeto Graal tem origem no Oracle Labs e não faz parte do OpenJDK. Sua imagem nativa GraalVM é um compilador Java AOT que produz executáveis ​​nativos hoje. Eles têm quatro vantagens sobre o compilador JIT do Java: inicialização rápida, menor uso de memória e CPU, menos vulnerabilidades de segurança e tamanhos de arquivo menores.

Mas essas conquistas têm um custo: o GraalVM Native Image impõe uma suposição chamada de mundo fechado em aplicativos Java que elimina toda uma categoria de aplicativos Java. Por quê? Porque Java é uma linguagem dinâmica e dá aos aplicativos muito poder em tempo de execução, como reflexões, carregamento de classes ou até mesmo construção de classes. E alguns desses recursos não funcionam no mundo fechado do GraalVM Native Image. É por isso que o Projeto Leyden agora quer "explorar um espectro de restrições, mais fracas do que a restrição do mundo fechado, e descobrir quais otimizações elas permitem". Ainda assim, Leyden "provavelmente [...] produzirá imagens totalmente estáticas", embora apenas "a longo prazo".

O OpenJDK já tentou a compilação AOT

O Project Leyden é a segunda tentativa do OpenJDK de compilação AOT. O primeiro esforço foi com a jaotc na JEP 295, Ahead-of-Time Compilation, entregue no JDK 9 em setembro de 2017. Assim como o GraalVM Native Image, utilizou o projeto Graal. Ao contrário do GraalVM Native Image, era altamente impopular: quando a Oracle removeu o  jaotc de suas compilações Java 16 , "ninguém reclamou", a Oracle observou secamente com JEP 410, Remove the Experimental AOT e JIT Compiler, entregue no JDK 17.

O Projeto Leyden teve uma história incomum para um projeto OpenJDK. O arquiteto da linguagem Java Mark Reinhold o propôs em abril de 2020, seguido pelo OpenJDK que o aprovou como projeto em junho de 2020. Mas o projeto não mostrou nenhum progresso visível nos dois anos entre essa aprovação e a criação de sua lista de discussão em maio de 2022. Isso é porque o projeto está apenas começando, focando " mais em conceitos do que em código " agora. Reinhold afirmou que componentes como o HotSpot JVM, o compilador C2, o compartilhamento de dados de classe de aplicativo (CDS) e a ferramenta  jlink de vinculação" são alvos de otimização. Notavelmente ausente dessa lista foi o CRaC, um projeto OpenJDK que reduz o tempo de inicialização carregando o estado do aplicativo Java do disco.

Um cálculo no verso do envelope mostra as datas de entrega possíveis. As versões LTS agora têm uma importância desproporcional no Java. Ben Evans, da empresa de monitoramento New Relic, anunciou na Devoxx UK 2022 que " nenhuma versão não LTS já ultrapassou 1% de participação de mercado ". Isso mostra que os desenvolvedores Java convencionais migram apenas de uma versão Java LTS para outra versão LTS.

Como o Projeto Leyden está em andamento, poucos resultados estarão prontos para produção em setembro de 2023 para o JDK 21, o próximo lançamento do LTS . Portanto, os desenvolvedores Java convencionais provavelmente verão apenas os primeiros resultados do Project Leyden com o lançamento do LTS depois disso, JDK 25, em setembro de 2025. Com base nessa suposição, o Project Leyden entregaria, no mínimo, a compilação AOT para executáveis ​​nativos com o JDK 29 em setembro de 2027.

Spring Boot reage ao projeto Leyden

Pelo menos alguns dos recursos considerados para o Projeto Leyden, como jlink ou CRaC, exigem suporte à estrutura do aplicativo para funcionar melhor. É por isso que a InfoQ entrou em contato com os desenvolvedores que representam Spring Boot, Quarkus e Micronaut para sua reação inicial ao anúncio do Project Leyden.

O líder do projeto Spring Framework, Juergen Hoeller, aprova o Projeto Leyden:

O Projeto Leyden é uma iniciativa promissora alinhada com a direção geral que estamos tomando no Spring Framework 6 e Spring Boot 3.

Hoeller também adota o CRaC para o Spring:

Os snapshots de heap CRaC podem se tornar uma opção comum para melhorar o tempo de inicialização de aplicativos baseados em Spring. Tirando o snapshot bem no final da fase de inicialização do aplicativo, dificilmente haveria qualquer arquivo aberto ou recursos de rede nesse ponto, de acordo com as expectativas do CRaC. O Spring ainda redefine seus caches comuns no final de uma atualização de contexto de aplicativo, limpando metadados relacionados à inicialização antes de repovoar dinamicamente os caches com metadados relacionados a solicitações. Em termos de contexto de aplicação reagindo especificamente a um evento de snapshot ou melhorando a "snapsafety" de componentes comuns, certamente tentaremos capacitar os primeiros adotantes na medida do tecnicamente viável em nossa linha Spring Framework 6.x.

Hoeller acha que o Spring dará suporte jlink ao Java Platform Module System (JPMS) em breve:

Os marcos atuais do Spring Framework 6.0 ainda não incluem descritores de informações de módulo. Isso está no roteiro para o milestone M6 em setembro, reavaliando a prontidão do sistema de módulos do ecossistema de terceiros à medida que avançamos para nossa fase de candidatos à versão 6.0. Com o Project Leyden potencialmente transformando jlink em uma ferramenta mais poderosa e versátil, pretendemos nos preparar não apenas para jlink's as capacidades atuais, mas também para sua evolução futura.

Quarkus reage ao projeto Leyden

O cofundador e co-líder da Quarkus, Jason Greene, comentou sobre o Projeto Leyden:

Estamos muito empolgados com o objetivo do projeto Leyden de revisar a especificação da linguagem Java para oferecer melhor suporte a imagens estáticas, compilação nativa e outras tecnologias, como checkpointing JVM. Além disso, ficamos felizes em ver o mundo fechado remanescente como uma provável meta de longo prazo para o projeto.

Greene adota o CRaC para Quarkus:

O suporte inicial para o projeto de pesquisa CRaC foi recentemente contribuído para o projeto Quarkus pelo líder CRaC. Como o Quarkus realiza a otimização do tempo de compilação, independentemente do tipo de destino do tempo de execução, você ainda vê economias consideráveis ​​ao executar no OpenJDK, não apenas no GraalVM. Adicionar uma abordagem de ponto de verificação, como CRaC, em cima do OpenJDK otimiza ainda mais o tempo de inicialização. Não traz economia de memória semelhante às imagens nativas, mas é uma opção futura interessante para aplicativos que preferem ou exigem execução de JVM.

No entanto, Greene está mais relutante em relação jlink ao JPMS em Quarkus:

A partir de hoje, jlink só traz benefícios para a sobrecarga de armazenamento de um aplicativo baseado em JVM (a sobrecarga de memória e o tempo de inicialização são essencialmente os mesmos sem ela). No entanto, a prática comum em um contêiner ou aplicativo Kubernetes é sobrepor uma imagem de base JVM padrão, o que já traz mais economia do que alternar todos os aplicativos para jlink (já que cada um agruparia sua própria JVM aparada). No caso de uma imagem nativa, os elementos refinados da JVM são compilados na imagem, então jlink não é útil neste cenário também. Da mesma forma, com o JPMS, o Quarkus já tem a noção de modularidade por meio de extensões do Quarkus, permitindo que você reduza seu conjunto de dependências apenas para o que você precisa. A abordagem adotada pelo Quarkus é compatível com o classpath simples e plano que a maioria do ecossistema Java e as ferramentas de compilação preferem hoje. Do lado do custo, mudar para um modelo de módulo JPMS puro conforme jlink necessário (sem módulos automáticos) significaria uma mudança radical não apenas no Quarkus, mas em muitas das bibliotecas nas quais o Quarkus se baseia. Antes de considerar uma mudança, gostaríamos de ver esses fatores se equilibrarem melhor.

Micronaut reage ao Projeto Leyden

Sergio del Amo Caballero, engenheiro de software principal da Object Computing, Inc. (OCI), não tinha uma declaração oficial do Micronaut Framework sobre o Projeto Leyden. Mas ele apontou para um problema recente do GitHub para adicionar suporte CRaC no Micronaut.

Caballero também compartilhou um clipe do YouTube de julho de 2020 com o criador do Micronaut, Graeme Rocher, comentando sobre o JPMS: o Micronaut suporta JPMS e publica arquivos de informações do módulo, mas precisa "equilibrar isso com o suporte ao Java 8". O JPMS foi adicionado no Java 9, mas o Micronaut 3.5, a versão atual, ainda roda no Java 8.

Conclusão

Até agora, o OpenJDK não abordou "os pontos problemáticos de longo prazo do tempo de inicialização lento do Java, do tempo lento para o desempenho máximo". Primeiro, seu jaotc compilador AOT não conseguiu ganhar força e foi aposentado. Então o Projeto Leyden começou a padronizar a compilação nativa em Java, mas ficou parado por dois anos.

Agora que o Project Leyen mudou para otimizar a compilação JIT, as coisas estão melhorando: tanto o Spring quanto o Quarkus adotam o CRaC para reduzir o tempo de inicialização. Mas quando se trata de tamanhos de aplicativos Java menores, apenas a Micronaut adere à sugestão do Projeto Leyden de usar o JPMS. O Spring planeja oferecer suporte ao JPMS na versão 6 até o final de 2022, embora o ecossistema Spring não possa. E a Quarkus atualmente não tem planos de adicionar o JPMS.

Os resultados, na forma de JEPs, do Projeto Leyden podem alcançar os principais desenvolvedores Java até o final de 2025, no mínimo. Portanto, pelo menos até então, a combinação do compilador GraalVM Native Image AOT com uma estrutura como Quarkus, Micronaut ou o próximo Spring Boot 3 continua sendo a melhor opção para evitar "tempo de inicialização lento do Java, tempo lento para desempenho máximo e grande área de cobertura ."

Fonte:

https://www.infoworld.com/article/3652336/java-19-may-be-quite-ambitious.amp.html