OpenJ9 - OpenJ9

Eclipse OpenJ9
Autor (es) original (is) IBM
Desenvolvedor (s) Eclipse Foundation
Versão estável
0.25.0 / 16 de março de 2021 ; 2 meses atrás  ( 2021-03-16 )
Repositório Edite isso no Wikidata
Escrito em C , C ++ , Java , montagem
Sistema operacional Linux , AIX , Windows , macOS , z / OS , IBM i
Modelo Máquina Virtual JAVA
Licença Licença Apache 2.0

Eclipse Public License 2.0

GNU General Public License, versão 2 com a GNU Classpath Exception

GNU General Public License, versão 2 com a exceção OpenJDK Assembly
Local na rede Internet www .eclipse .org / openj9 /  Edite isso no Wikidata

Eclipse OpenJ9 (anteriormente conhecido como IBM J9 ) é uma implementação de Java virtual machine (JVM) de alto desempenho e escalonável que é totalmente compatível com a Java Virtual Machine Specification.

O OpenJ9 pode ser construído a partir do código-fonte ou pode ser usado com binários pré-construídos disponíveis no projeto AdoptOpenJDK para várias plataformas, incluindo Linux e Windows. OpenJ9 também é um componente principal do kit de desenvolvedor IBM, que está integrado em muitos produtos de middleware IBM, incluindo WebSphere Application Server e Websphere Liberty . OpenJ9 também é um componente do Open Liberty.

Extensas opções de configuração garantem que a JVM possa ser ajustada para satisfazer os requisitos de uma ampla gama de aplicativos Java, desde aplicativos corporativos complexos executados em hardware de mainframe até aplicativos de curta duração executados em serviços de nuvem baseados em contêiner.

História

O OpenJ9 pode traçar suas raízes no produto ENVY / Smalltalk desenvolvido pela Object Technology International (OTI). A IBM comprou a OTI em 1996 por sua experiência e produtos em Smalltalk . No entanto, quando a linguagem Java emergiu como uma linguagem líder para o mercado corporativo, a VM Smalltalk existente foi adaptada para processar bytecodes Java. O nome J9 evoluiu da convenção de nomenclatura para o código-fonte Smalltalk, K8 . K → J (um passo para trás) porque os desenvolvedores acreditavam que Smalltalk era melhor do que Java, mas 8 → 9 (um passo para frente) porque a nova VM seria melhor do que antes.

O J9 JVM tornou-se o mecanismo de tempo de execução para muitos produtos de middleware IBMs Enterprise, onde construiu sua reputação de alto desempenho, escalabilidade e confiabilidade.

Em 2017, J9 se tornou um projeto da Eclipse Foundation com o nome de Eclipse OpenJ9 . A IBM continua a estar ativamente envolvida no projeto e a colocar este Java VM no centro de muitas ofertas de software. Na Eclipse Foundation, o OpenJ9 é classificado como um projeto de incubadora, com o primeiro lançamento, v0.8.0, entregue em 2018.

Características

O Eclipse OpenJ9 JVM é totalmente compatível com a especificação Java JVM. A mesma versão do JVM pode ser usada no OpenJDK 8 e versões posteriores, o que significa que muitos recursos e melhorias podem ser explorados por aplicativos executados em diferentes versões do Java. Em comparação com o HotSpot VM da Oracle , o OpenJ9 apresenta maior desempenho de inicialização e menor consumo de memória com um rendimento geral semelhante.

O Eclipse OpenJ9 incorpora o Eclipse OMR , que fornece componentes de tempo de execução principais que podem ser usados ​​para construir ambientes de tempo de execução para diferentes linguagens de programação. No projeto OpenJ9, uma camada extra de código adiciona a semântica da linguagem para fornecer um ambiente de tempo de execução para aplicativos Java.

Os componentes que compõem o Eclipse OpenJ9 são descritos nas seguintes seções:

Compilador JIT

O Just-In-Time (JIT) melhora o desempenho de aplicativos Java ao compilar bytecode Java de plataforma neutra em código de máquina nativo em tempo de execução. Nem todo método chamado por um aplicativo é compilado. Em vez disso, o OpenJ9 registra o número de vezes que um método é chamado e dispara a compilação JIT em um limite predefinido. O compilador JIT compila métodos em diferentes níveis de otimização: frio , quente , quente , muito quente (com criação de perfil) ou escaldante . Quanto mais quente for o nível de otimização, melhor será o desempenho esperado, mas maior será o custo em termos de CPU e memória. Os níveis de otimização mais altos usam técnicas especiais, como análise de escape e eliminação de redundância parcial, ou loop por certas sequências de otimização mais vezes. Embora essas técnicas usem mais CPU e memória, o desempenho aprimorado fornecido pelas otimizações pode fazer a compensação valer a pena.

Compilador AOT

A compilação Ahead of Time (AOT) é um mecanismo para melhorar o desempenho de inicialização. Os métodos são compilados dinamicamente em código AOT no tempo de execução, o que permite que a JVM inicie um aplicativo mais rapidamente. AOT é habilitado automaticamente quando o compartilhamento de dados de classe é usado ( -Xshareclasses ) e não requer nenhum ajuste especial. O OpenJ9 escolhe automaticamente quais métodos compilar com base em heurísticas que identificam a fase de inicialização de grandes aplicativos. Para aplicativos pequenos ou curtos, a opção -Xtune: virtualized deve ser adicionada para obter o máximo do código compilado AOT.

Compartilhamento de dados de classe

Compartilhar dados de classe entre JVMs tem dois benefícios principais:

  1. O desempenho de inicialização é aprimorado colocando classes que um aplicativo precisa ao inicializar em um cache de classes compartilhadas.
  2. A área de cobertura da memória é reduzida pelo compartilhamento de classes comuns entre aplicativos executados em VMs Java separadas.

Ao contrário de outras implementações de compartilhamento de dados de classe (CDS), habilitar o recurso no OpenJ9 requer apenas uma etapa: definir -Xshareclasses na linha de comando ao iniciar seu aplicativo. Quando especificado, o OpenJ9 cria um arquivo mapeado na memória para armazenar e compartilhar as classes na memória. Por padrão, o OpenJ9 sempre compartilha as classes de bootstrap e de aplicativo que são carregadas pelo carregador de classes do sistema padrão. Outro benefício da implementação do OpenJ9 CDS é que o cache é atualizado dinamicamente. Portanto, quando um aplicativo carrega novas classes, a JVM as armazena automaticamente no cache sem qualquer intervenção do usuário.

O OpenJ9 também fornece uma API auxiliar pública para integrar o suporte ao compartilhamento de classes em carregadores de classes personalizados, além de vários utilitários para gerenciar caches ativos.

Coletor de lixo

Para evitar que os aplicativos fiquem sem memória, os objetos no heap Java que não são mais necessários devem ser recuperados. Este processo é conhecido como coleta de lixo (GC). O OpenJ9 fornece várias políticas de coleta de lixo projetadas em torno de diferentes tipos de aplicativos e cargas de trabalho. A escolha da política certa depende dos objetivos de uso e desempenho. Por padrão, o OpenJ9 usa a -Xgcpolicy:gencon política Generational Concurrent ( ), que é mais adequada para aplicativos transacionais que possuem muitos objetos de curta duração. Políticas alternativas estão disponíveis, incluindo aquelas que atendem a aplicativos com grandes heaps Java ( -Xgcpolicy:balanced ), aplicativos que são sensíveis ao tempo de resposta ( -Xgcpolicy:metronome ) ou aplicativos que requerem alto rendimento de aplicativo ( -Xgcpolicy:optthruput ).

Uma opção de "ajuste ocioso" ( -XX:+IdleTuningGcOnIdle ) aciona a coleta de lixo no OpenJ9 quando o aplicativo está ocioso. Isso reduz o consumo de memória, o que é significativo para alguns planos de cobrança de hospedagem virtual .

Servidor JIT

Em janeiro de 2020, OpenJ9 entregou um recurso experimental para JIT compilar código fora da JVM e remotamente em um servidor.

Componente de diagnóstico

OpenJ9 contém extensos utilitários de rastreamento e depuração para ajudar a identificar, isolar e resolver problemas de tempo de execução. Diferentes tipos de dados de diagnóstico são produzidos automaticamente por padrão quando certos eventos ocorrem, mas também podem ser acionados a partir da linha de comando. Os tipos de dados incluem:

Despejos de Java
Eles são produzidos quando a JVM termina inesperadamente por causa de um sinal do sistema operacional, exceção OutOfMemoryError ou uma combinação de pressionamento de tecla iniciada pelo usuário. Os dumps Java resumem o estado da JVM quando o evento ocorre, com a maioria das informações relacionadas aos componentes da JVM.
Depósitos de pilha
Os dumps de heap mostram todos os objetos ativos no heap Java quando a JVM termina devido a uma exceção OutOfMemoryError ou quando solicitado por um usuário. As informações incluem o endereço do objeto, tipo ou nome da classe, tamanho e referências a outros objetos. A análise de dumps de heap pode informar quais objetos estão usando grandes quantidades de memória no heap Java e por que eles não estão sendo coletados como lixo.
Despejos de sistema
Freqüentemente conhecidos como core dumps, são específicos da plataforma e contêm um dump binário bruto da memória do processo. Este dump possui uma cópia completa do heap Java, incluindo o conteúdo de todos os objetos Java no aplicativo. As ferramentas OpenJ9 estão disponíveis para processar o dump do sistema em um formato legível para análise.
Dados de coleta de lixo
Para analisar problemas de coleta de lixo, você pode habilitar o registro detalhado, que fornece dados sobre todas as operações de coleta de lixo, incluindo inicialização, processamento de interrupção do mundo, finalização, processamento de referência e falhas de alocação. Para uma análise ainda mais detalhada, você pode ativar o rastreamento da coleta de lixo.
Dados de rastreamento
O recurso de rastreio OpenJ9 pode ser usado para rastrear aplicativos, métodos Java ou operações JVM internas com impacto mínimo no desempenho.
Dados JIT
Se ocorrer uma falha de proteção geral ou evento de aborto, o JIT produz um pequeno dump binário que pode ser analisado pelos desenvolvedores do OpenJ9 para ajudar a determinar a causa raiz.
Dados de classes compartilhadas
O componente de dados de classes compartilhadas fornece algumas opções detalhadas que podem ser usadas no tempo de execução para mostrar a atividade do cache. Os printStats e printAllStats utilitários permitem analisar o conteúdo de um cache de classe compartilhada.

O componente de diagnóstico também inclui a interface de programação de aplicativo DTFJ, que pode ser usada para construir ferramentas de diagnóstico. O DTFJ trabalha com dados de um dump do sistema ou um dump Java.

Adoção

Veja também

Referências

links externos