Atualização de Serviço 5

Saída da versão Java™: A saída das opções da linha de comandos java -version e java -showversion e a propriedade do sistema java.version são atualizadas para conter o número da construção Oracle no qual o SDK IBM é baseado. Por exemplo, a sequência 1.8.0_141 indica que o SDK é baseado na atualização 141 (U141) das bibliotecas de classes Oracle SE 1.8.
A saída também contém mudanças para indicar os números de Versão, Liberação, Modificação e Fix Pack (V.R.M.F). Por exemplo, Java(TM) SE Runtime Environment (build 8.0.5.0 ... reflete Versão 8, Service Refresh 5.

Gerenciando o heap do objeto Java quando a JVM está inativa (Linux® apenas) .

As opções de ajuste a seguir estão disponíveis para gerenciar o heap do objeto Java quando a JVM está inativa:

A opção -XX:IdleTuningMinIdleWaitTime controla o tempo em que a JVM deve ficar ociosa antes que as outras opções de ajuste tenham efeito.
A opção -XX:[+|-]IdleTuningCompactOnIdle controla se o coletor de lixo deve coletar e compactar o heap de objetos Java, o que melhora o uso do heap.
A opção -XX:[+|-]IdleTuningGcOnIdle controla se as páginas de memória livres são liberadas para reduzir o espaço ocupado pela memória.
A opção -XX:IdleTuningMinFreeHeapOnIdle pode ser usada com ' -XX:+IdleTuningGcOnIdle para definir a quantidade mínima de memória livre que deve permanecer no heap do objeto.
Essa opção se aplica apenas às arquiteturas Linux em x86-32 e x86-64 quando a política de coleta de lixo (gencon) estiver em uso. Essa opção não entra em vigor se o heap do objeto está configurado para uso de páginas grandes.

Novo modo de coleta de lixo para horários de pausa reduzidos

Está disponível um novo modo que funciona com a política de coleta de lixo Generational Concurrent (gencon). Quando esse modo é ativado, a JVM tenta reduzir os tempos de pausa de GC para aplicativos heap grandes e sensíveis ao tempo de resposta, que melhoram a estabilidade do rendimento. O modo é controlado pela opção -Xgc:concurrentScavenge , que requer um mínimo de hardware z/OS® V2R3 (ou z/OS V2R2 com APAR OA51643) e z14 e é suportado apenas para a JVM de 64 bits. Se o requisito de sistema operacional e de hardware não for atendido, a opção será ignorada.

Capacidade para o compilador JIT alocar memória superior à barra de 2 GB (somentez/OS )

Em sistemas z/OS V2R3 , o modo de residência para programas de 64 bits (RMODE64) é ativado por padrão. Esse recurso permite que o JIT aloque caches de código executável maiores que a barra de memória 2 GB. Esse comportamento é o padrão, a menos que a opção -Xjit:disableRMODE64 esteja especificada na linha de comandos. Para obter mais informações, consulte disableRMODE64 (z/OS apenas)..

Ajustando o cache de classes compartilhadas

Agora é possível criar um limite flexível no conteúdo do cache de classes compartilhadas que pode ser consultado e ajustado programaticamente usando um MXBean ou modificado usando as opções da linha de comandos A capacidade para monitorar e ajustar o tamanho do cache pode ajudar a reduzir a área de cobertura e o tempo de inicialização ao executar múltiplos servidores semelhantes.

Se a opção -Xscmx for especificada como nas liberações anteriores, não haverá mudança de comportamento; essa opção especifica o tamanho de um novo cache de classe compartilhada. No entanto, se a nova opção -XX:SharedCacheHardLimit também for especificada, a opção -Xscmx especificará o tamanho máximo temporário no novo cache de classe compartilhada, e a opção -XX:SharedCacheHardLimit especificará o tamanho máximo real. Quando o limite máximo flexível é atingido (o cache está flexivelmente cheio), dados não podem ser incluídos no cache, a menos que você aumente o limite máximo flexível. Para obter mais informações, consulte a opção -Xscmx e a opção-XX:SharedCacheHardLimit.

Compatibilidade do MXBean melhorada

As extensões da interface de monitoramento e de gerenciamento das APIs java.lang.mangement são atualizadas para melhorar a compatibilidade com as classes com.sun.management a seguir.

GarbageCollectorMXBean
GarbageCollectionNotificationInfo
GcInfo
OperatingSystemMXBean
UnixOperatingSystemMXBean

Essa compatibilidade inclui compatibilidade e implementação de cast de classe do conjunto completo de APIs fornecidas por essas classes com.sun.management. Para obter mais informações, consulte a Referência da API do Language Management.

Se você depende da saída das extensões da interface anterior, as novas opções a seguir estão disponíveis para reverter para o comportamento dessa implementação:

-Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns
-XX:[+|-]HeapManagementMXBeanCompatibility

Para obter mais informações sobre essas opções, consulte Alteração no valor de retorno do método OperatingSystemMXBean.getProcessCpuTime() e Monitoramento aprimorado dos pools de memória e da atividade de coleta de lixo.

Mude o valor de retorno do método OperatingSystemMXBean.getProcessCpuTime()

O método OperatingSystemMXBean.getProcessCpuTime() foi mudado para retornar valores em nanossegundos, em vez de em centenas de nanossegundos, para compatibilidade com as interfaces com.sun.management.OperatingSystemMXBean e UnixOperatingSystemMXBean. É possível reverter para o comportamento anterior usando a propriedade de sistema -Dcom.ibm.lang.management.OperatingSystemMXBean.isCpuTime100ns opção .

Monitoramento de conjuntos de memórias e atividade de coleta de lixo melhorados

Para ajudá-lo a entender o comportamento de seu aplicativo, os aprimoramentos são feitos nos MXbeans do Coletor de Lixo e do Conjunto de Memória do IBM® . Em liberações anteriores, as informações do conjunto de memórias são agregadas e relatadas para todo o heap Java.. Nessa liberação, informações mais detalhadas podem ser obtidas sobre os conjuntos de memórias e sobre atividades do coletor de lixo para uma política de coleta de lixo.

Se seu aplicativo de monitoramento for escrito para esperar somente um conjunto de memórias heap ou se ele depende do nome de conjunto de memórias Java heap, é possível reverter para a implementação anterior usando a opção -XX:+HeapManagementMXBeanCompatibility. Para obter mais informações sobre essa opção e os novos nomes " MemoryPool e " GarbageCollector fornecidos, consulte a opção -XX:[+|-]HeapManagementMXBeanCompatibility.

-XX:[+|-]InterleaveMemory desativado por padrão (AIX®, Linuxe Windows)

A intercalação de memória agora está desativada por padrão. Para obter mais informações, consulte a opção -XX:[+|-]InterleaveMemory (AIX, Linux e Windows).

Os agentes que se conectam tardiamente podem redefinir ou retransformar classes

Os agentes que se conectam tardiamente podem redefinir ou retransformar classes por padrão. Não é mais necessário usar a opção -XX:+EnableHCR , descrita em IBM SDK, Java Technology Edition, Versão 8: Informações complementares, para ativar essa função. Para obter mais informações sobre a API de conexão Java, consulte API de Conexão Java na documentação do usuário OpenJ9 .

Informações de diagnóstico melhoradas para ganchos de MV

Novos pontos de rastreio foram incluídos e são acionados quando os retornos de chamada para um gancho de MV, como o gancho de descarregamento de classe, excedem um limite de tempo. Quando acionado, uma nova seção é produzida na saída de dump Java Os pontos de rastreio e dump Java fornecem informações suficientes para identificar os retornos de chamadas.

Para obter mais informações sobre oHOOKde um arquivo dump Java, consulte Gancho (HOOK) na OpenJ9 documentação do usuário. Para obter mais informações sobre pontos de rastreio, consulte Rastreando aplicativos Java no J9 VM reference.

Não é mais necessária uma página extra de memória ao usar tamanhos de página grandes (somenteLinux on IBM Z e z/OS )

Ao especificar um tamanho de heap de objeto, não é mais necessário que outra página de memória seja múltipla de um tamanho de página grande. Em liberações anteriores, se o tamanho da página era 2 GB, por exemplo, a configuração -Xmx2G realmente usou 4 GB de memória. Para evitar o uso de mais memória, você teve que tornar o tamanho de heap um pouco menor do que um número integral de páginas subtraindo pelo menos 16 bytes. Por exemplo, para um tamanho de página de 2 GB, foi necessário especificar um tamanho máximo de heap de -Xmx2147483632 (2147483648 menos 16 bytes) em vez de -Xmx2048m (2 GB). Para um tamanho de página de 4 GB, era necessário especificar um tamanho de heap de -Xmx4294967280 (4.294.967.296 menos 16 bytes) em vez de -Xmx4096m (4 GB) e assim por diante. Nesta liberação, não é necessário reduzir o tamanho de heap.

O valor padrão para o tamanho de heap Java inicial

A opção -Xms configura o tamanho inicial do heap Java. Se essa opção não for configurada na linha de comandos, o coletor de lixo configurará um tamanho inicial de 8 MB por padrão. Em liberações anteriores do SDK, o coletor de lixo configura um valor padrão de 4 MB. Para obter mais informações sobre essa configuração, consulte -Xms option na OpenJ9 documentação do usuário..

Opção -Xthr:<fastNotify|noFastNotify>

Agora é possível usar -Xthr:fastNotify para aumentar o rendimento de um aplicativo, especificamente quando o uso regular de wait e notify faz com que um número grande de encadeamentos tente adquirir um monitor Java. Para obter mais informações, consulte -Xthr option na OpenJ9 user documentation.

Algumas subopções -Xzero não mais suportadas

As subopções j9zip, noj9zip, sharezip e nosharezip não são mais suportadas. Se você especificar essas opções, elas serão analisadas, mas nada será feito. Para obter mais informações sobre essas opções, consulte -Xms option na OpenJ9 documentação do usuário.

As exceções da API Attach agora começam com com.sun

As exceções da API Attach são agora prefixadas com com.sun.tools.attach, em vez de com.ibm.tools.attach.

Recurso de Instrumentação de Tempo de Execução desativado por padrão (somenteAIX, Linuxe z/OS )

Em atualizações anteriores, o recurso de RI era ativado por padrão em todas as plataformas que o suportam. O recurso de RI está agora desativado por padrão. Para obter mais informações, consulte -XX:[+|-]RuntimeInstrumentation na documentação do usuário doOpenJ9.

Mudanças no Strings para suportar CompactStrings

Para dar suporte ao Strings compacto (-XX:+CompactStrings), java.lang.String não contém mais um campo de deslocamento, que é usado para indicar o início do String nos dados subjacentes do char[] . O desempenho pode ser afetado ao usar os métodos a seguir em seu código para valores de beginIndex diferentes de zero:

String.substring(int beginIndex)
String.substring(int beginIndex, int endIndex)

Em liberações anteriores, um novo String é criado, mas o char[] subjacente é compartilhado com o String original para que nenhum dado char[] seja copiado.. Se o desempenho for significativamente comprometido porque os dados do char[] agora estão sendo copiados, tente reimplementar o código para evitar copiar os dados do String .

Nota: os aplicativos que são gravados para executar em implementações Java que usam a VM HotSpot não são afetados, porque os dados String são copiados, mesmo ao usar um beginIndex de zero.

Tecnologia de avaliação de objeto empacotado removida

A visualização da tecnologia de objeto empacotado não está mais disponível.

Fix pack 5 da atualização de serviço 5

Esta liberação contém as correções mais recentes da IBM , a Atualização de Correção Crítica (CPU) Oracle de outubro de 2017 e as atualizações a seguir:

Mudanças nas informações da versão Java

Saída do comando java -version é alterada. Aqui está um exemplo:

java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 8.0.5.5 - pxa6480sr5fp5-20171109_02(SR5 FP5))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64 Compressed References 20171102_369060 (JIT enabled, AOT enabled)
OpenJ9 - 7ade437
OMR - 1b656cb
IBM - 59c3d96)
JCL - 20171109_01 based on Oracle jdk8u151-b12

A linha que começa com OpenJ9 substitui as linhas J9VM e JIT na saída de atualizações anteriores, porque esses componentes agora são contribuídos para o Eclipse Foundation sob o projeto Eclipse OpenJ9

Suporte AIX

A partir desta atualização e para todas as correções temporárias futuras (ifixes), o nível mínimo suportado do AIX 6.1 agora é TL9. Se você estiver em um nível de manutenção inferior, o uso de determinadas extensões de API do com.ibm.language.management poderá resultar nas exceções ProcessorUsageRetrievalException e GuestOSInfoRetrievalException

Configurando a contagem do descritor de arquivo aberto para o processo Java

O número máximo de descritores de arquivos abertos em um processo é controlado por um sistema operacional Em sistemas UNIX, você configura esse número configurando o limite máximo do sistema ou ulimit

Para evitar o uso excessivo de recursos durante o processamento de inicialização, o IBM SDK limita a contagem máxima de descritores de arquivo para um processo Java para 64K São aplicadas as seguintes regras:

Se o valor ulimit for maior que 64K, a contagem do descritor de arquivo será padronizada para 64K.
Se o valor ulimit for menor que 64K, a contagem do descritor de arquivo corresponderá ao valor de ulimit.

Se seu aplicativo precisar de um número maior de descritores de arquivos abertos ou o desempenho de inicialização for afetado pelo limite padrão configurado, será possível configurar o valor configurando a variável de ambiente a seguir:

export IBM_JAVA_FDLIMIT=file_descriptor_count

em que file_descriptor_count é um valor que é menor que seu sistema ulimit.

Fix pack 10 da atualização de serviço 5

Esta liberação contém as correções mais recentes da IBM e a Oracle Critical Patch Update (CPU) de janeiro de 2018.

Verificação de segurança

Para a VM Eclipse OpenJ9, para melhorar a segurança, as verificações de segurança nas APIs a seguir são agora ativadas por padrão, quando o SecurityManger é ativado:

com.ibm.jvm.Dump.JavaDump()
com.ibm.jvm.Dump.HeapDump()
com.ibm.jvm.Dump.SnapDump()
com.ibm.jvm.Log.QueryOptions()
com.ibm.jvm.Log.SetOptions(String)
com.ibm.jvm.Trace.set(String)
com.ibm.jvm.Trace.snap()
com.ibm.jvm.Trace.suspend()
com.ibm.jvm.Trace.suspendThis()
com.ibm.jvm.Trace.resume()
com.ibm.jvm.Trace.resumeThis()
com.ibm.jvm.Trace.registerApplication(String, String[])
com.ibm.jvm.Trace.trace(<any parameters>)

É possível desativar a verificação de segurança dessas APIs configurando as seguintes propriedades de sistema na linha de comandos:

-Dcom.ibm.jvm.enableLegacyTraceSecurity=false
-Dcom.ibm.jvm.enableLegacyDumpSecurity=false
-Dcom.ibm.jvm.enableLegacyLogSecurity=false

Fix Pack 15 da Service Refresh 5

Essa liberação contém as mudanças a seguir, além das correções mais recentes da IBM e da Atualização de Correção Crítica (CPU) de abril de 2018 Oracle :

Verificação de segurança

Quando um SecurityManager está sendo usado com compartilhamento de dados de classe e o aplicativo em execução está chamando as APIs getSharedCacheInfo() ou destroySharedCache() do com.ibm.oti.shared.SharedClassUtilities, deve-se conceder o código que chama essas APIs a SharedClassesNamedPermission apropriada. Por exemplo, consulte Suporte para carregadores de classes customizados na documentação do usuário do OpenJ9 .

Novo MXBean para controlar o processamento de dump

A produção de dados diagnósticos de dump e de rastreio pode ser controlada pelas opções da linha de comandos -Xdump na inicialização Se desejar alterar a configuração de dump, deve-se reiniciar o aplicativo Para evitar a reinicialização, é possível usar a interface de processamento de aplicativos (API) com.ibm.jvm.Dump para mudar dinamicamente a configuração. Um novo MXBean agora está disponível que chama os métodos da API de Dump para que você possa configurar dinamicamente o dump enquanto monitora remotamente um aplicativo que está em execução em um servidor ou contêiner remoto

Para obter mais informações sobre as opções de configuração, consulte a documentação da API

Suporte de hardware

O suporte ao IBM POWER9 foi adicionado nessa atualização, mas correções importantes, incluindo correções de segurança, foram feitas desde então. Se você estiver usando o IBM POWER9, deverá fazer upgrade para pelo menos o fix pack 30.

Suporte ao sistema operacional

Os sistemas operacionais a seguir são agora suportados:

Red Hat® Enterprise Linux (RHEL) 7.5
Ubuntu 18.04

Agora, o modo de varredura simultânea é compatível com o Linux on IBM Z

A opção -Xgc:concurrentScavenge agora é suportada no hardware IBM z14 com RHEL 7.5 e Ubuntu 18.04 nos níveis e configurações a seguir:

Sistemas operacionais

RHEL 7.5 (nível kernel mínimo 4.14)
Ubuntu 18.04

Hipervisores

Soluções KVM com QEMU 2.10 ou posterior e um nível mínimo de kernel do host 4.12

Nova variável de ambiente para alternar entre conversores ICONV e Java no z/OS

Por padrão, o utilitário ICONV é usado para converter caracteres de uma página de códigos configurada para outra. No entanto, em algumas instâncias, ICONV converte para um caractere que não é reconhecido em determinadas plataformas. Por exemplo, ICONV converte o código EBCDIC x'25' (feed de linha) em Unicode '\u0085' (próxima linha), que causa problemas para analisadores XML.

A variável de ambiente a seguir pode ser configurada para selecionar o conversor Java:

USE_JAVA_CONV=1

Por padrão, a variável de ambiente é configurada como USE_JAVA_CONV=0, que usa o utilitário ICON.

Atualização de serviço 5, pacote de correção 16

O fix pack 16 inclui os novos recursos a seguir na máquina virtual Eclipse OpenJ9 :

Suporte estendido para o recurso de ajuste inativo

O recurso de ajuste inativo na VM Eclipse OpenJ9 mantém sua área de cobertura de memória pequena, liberando a memória não usada de volta para o sistema operacional Esse recurso agora está disponível no Linux para IBM POWER ® e IBM Z® , além de arquiteturas x86 quando usado com a política de coleta de lixo simultânea de geração (gencon). Para obter mais informações sobre esse recurso, consulte as opções da linha de comandos a seguir (na OpenJ9 documentação do usuário), que controlam esse comportamento:

Mude para o tamanho máximo de heap Java padrão para aplicativos que são executados no contêiner

Ao usar a tecnologia de contêiner, os aplicativos geralmente são executados por conta própria e não precisam competir pela memória Nessa atualização, as mudanças são introduzidas para detectar quando a VM OpenJ9 está em execução dentro de um contêiner. Se seu aplicativo estiver em execução em um contêiner e você desejar que a VM aloque uma fração maior de memória para o heap Java, agora será possível configurar a opção -XX:+UseContainerSupport na linha de comandos para obter uma porcentagem maior de memória disponível. A porcentagem alocada depende do limite de memória do contêiner.. Para obter mais informações, consulte -XX:[+|-]UseContainerSupport na documentação do usuário doOpenJ9.

Atualização de serviço 5, pacote de correção 17

O fix pack 17 inclui os novos recursos a seguir na máquina virtual Eclipse OpenJ9 :

Nova política de coleta de lixo

Uma nova política é introduzida no Eclipse OpenJ9 VM que expande o heap Java da maneira normal, mas não recupera a memória por meio de operações de coleta de lixo Esse modo é útil para aplicativos de curta duração em que existe memória suficiente para atender aos requisitos de tempo de execução... Para obter mais informações, consulte -Xgcpolicy:nogc na documentação do usuário do OpenJ9

Especificando o tamanho máximo de heap Java como um valor de porcentagem

A VM do OpenJ9 agora suporta a configuração do tamanho de heap como uma porcentagem da memória física As seguintes opções de Oracle HotSpot são reconhecidas e podem ser configuradas para a VM:

-XX:InitialRAMPercentage ( documentação do usuário OpenJ9 )
-XX:MaxRAMPercentage ( documentação do usuário OpenJ9 )

Se seu aplicativo estiver em execução em um contêiner e você tiver especificado -XX:+UseContainerSupport, o tamanho de heap padrão para contêineres e os valores para essas novas opções serão baseados na memória do contêiner disponível.

Suporte de classes compartilhadas para arquivos jar aninhados

São feitas mudanças na interface de programação de aplicativos com.ibm.oti.shared para suportar arquivos jar aninhados.

Atualização de serviço 5 fix pack 20

Esta liberação contém as correções mais recentes da IBM e a Atualização de Correção Crítica (CPU) do Oracle de julho de 2018.

Atualização de serviço 5, pacote de correção 25

Esta liberação contém as correções mais recentes da IBM e a atualização de correção crítica (CPU) do Oracle de outubro de 2018.

A documentação para suportar a IBM SDK, Java Technology Edition Versão 8 é alterada nesta atualização Além deste guia do SDK e da referência de suporte da VM J9, a documentação IBM agora contém a documentação do usuário da VM Eclipse OpenJ9. Algum material localizado anteriormente na referência da VM J9 é removido para evitar a duplicação O redirecionamento está em vigor para minimizar o impacto dessa mudança

Para qualquer nova mudança na VM do Eclipse OpenJ9 , consulte as notas sobre a liberação a seguir na OpenJ9:

Versão 0.10.0

Atualização de serviço 5 fix pack 26

O fix pack 26 inclui os novos recursos a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário OpenJ9 :

Novas subopções de compartilhamento de dados de classe

A opção -Xshareclasses:bootClassesOnly desativa o armazenamento em cache de classes que são carregadas por carregadores de classes não de autoinicialização. Essa subopção também ativa a subopção nonfatal , que permite que a VM seja iniciada mesmo se houver um erro ao criar o cache de classes compartilhadas..

A opção -Xshareclasses:fatal evita que a VM seja iniciada se houver um erro ao criar o cache de classes compartilhadas Você pode desejar ativar essa subopção ao utilizar a subopção -Xshareclasses:bootClassesOnly , para solucionar problemas ao criar o cache

O reconhecimento do contêiner na VM OpenJ9 agora está ativado por padrão

Ao usar a tecnologia de contêiner, os aplicativos geralmente são executados por conta própria e não precisam competir pela memória Se a VM detectar que está em execução em um ambiente de contêiner e um limite de memória para o contêiner estiver configurado, a VM ajustará automaticamente o tamanho máximo de heap Java padrão.

Em liberações anteriores, esse comportamento era ativado configurando a opção -XX:+UseContainerSupport .. Essa configuração agora é o padrão

O modo de coleta de lixo sem pausa agora está disponível nas plataformas Linux x86

O modo de coleta de lixo sem pausa é destinado a aplicativos de heap grande, sensíveis ao tempo de respostas. Quando ativado, a VM tenta reduzir os tempos de pausa de GC. Em liberações anteriores, o modo de coleta de lixo sem pausa (-Xgc:concurrentScavenge) estava disponível apenas no hardware IBM z14 . Esse modo agora está disponível nas plataformas x86 Linux de 64 bits..

Nota: A política de coleta de lixo (gencon) simultânea de geração deve ser usada. (Esta é a política padrão.).

Agora é possível restringir códigos hash de identidade a valores não negativos

O OpenJ9 permite ambos os códigos hash de identidade positivos e negativos, que podem ser problemáticos se seu programa (incorretamente) assumir que os códigos hash podem ser positivos apenas. No entanto, agora é possível usar a opção -XX:+PositiveIdentityHash para limitar os códigos hash de identidade para valores não negativos Como a limitação de códigos hash de identidade a valores não negativos pode ter um impacto no desempenho de operações com hash intensivo, essa opção não é ativada por padrão

Suporte para opções de OpenJDK HotSpot

Para compatibilidade, as opções de ponto de acesso OpenJDK a seguir agora são suportadas pelo OpenJ9:

-XX:MaxHeapSize, que é equivalente à opção -Xmx ..
-XX:InitialHeapSize, que é equivalente à opção -Xms ..

IBM_JAVA_OPTIONS foi descontinuado

A variável de ambiente IBM_JAVA_OPTIONS foi descontinuada. Em vez disso, use a nova variável de ambiente OPENJ9_JAVA_OPTIONS .

Atualização de serviço 5, pacote de correção 27

O fix pack 27 inclui os novos recursos a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário do OpenJ9 :

Flexibilidade melhorada para gerenciar o tamanho do cache de código JIT: O cache de código JIT armazena o código nativo de métodos Java compilados.. Por padrão, o tamanho do cache de código é 256 MB para uma VM de 64 bits e 64 MB para uma VM de 31 /32 bits. Em liberações anteriores, o tamanho do cache de código poderia ser aumentado do valor padrão usando a opção da linha de comandos -Xcodecachetotal . Nesta liberação, o tamanho também pode ser diminuído usando essa opção, com um tamanho mínimo de 2 MB. O tamanho do cache de código JIT também afeta o tamanho do cache de dados JIT, que contém metadados sobre métodos compilados. Se você usar a opção -Xcodecachetotal para gerenciar o tamanho do cache de código, o tamanho do cache de dados será ajustada pela mesma proporção

Atualização de serviço 5 fix pack 30

O fix pack 30 inclui os novos recursos a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário OpenJ9 :

Suporte melhorado para coleta de lixo sem pausa

O modo de scavenge simultâneo (-Xgc:concurrentScavenge) agora é suportado em sistemas operacionais Windows de 64 bits.

O ajuste inativo é ativado por padrão quando a VM é executada em um contêiner do Docker

Em uma liberação anterior, um conjunto de opções de ajuste inativo foi introduzido para gerenciar a área de cobertura do heap Java quando a VM do OpenJ9 está em um estado inativo As duas opções a seguir agora são ativadas por padrão quando a VM OpenJ9 detecta que ela está em execução em um contêiner e que a VM entrou em um estado inativo:

-XX:[+|-]IdleTuningGcOnIdle, que executa um ciclo de coleta de lixo e libera páginas de memória livre de volta para o sistema operacional
-XX:[+|-]IdleTuningCompactOnIdle, que compacta o heap do objeto, para reduzir a fragmentação

Por padrão, a VM é verificada a partir de 180 segundos para detectar um status inativo. Para controlar o tempo de espera entre as verificações, use a opção ' -XX:[+|-]IdleTuningMinIdleWaitTime ( documentação do usuário OpenJ9 ). Para desativar a detecção inativa, configure o valor como 0.

Mudanças nas permissões de diretório de cache de classes compartilhadas padrão (não Windows)

Se você não usar a subopção cachDirPerm para especificar permissões para um diretório de cache de classes compartilhadas e o diretório de cache não for o padrão /tmp/javasharedresources , as mudanças a seguir serão aplicadas:

Ao criar um novo diretório de cache, as permissões padrão são agora mais estritas.
Se o diretório de cache já existir, as permissões agora permanecerão inalteradas (anteriormente, quando um cache foi aberto usando esse diretório, as permissões seriam configuradas como 0777)..

Para obter mais informações, consulte -Xshareclasses na documentação do usuário do OpenJ9

Atualização de serviço 5, pacote de correção 31

O fix pack 31 inclui os novos recursos a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário OpenJ9 :

Melhores informações de diagnóstico para sistemas Linux que implementam grupos de controlo

Se você usar grupos de controle (cgroups) para gerenciar recursos em sistemas Linux , as informações sobre limites de CPU e de memória agora serão registradas em um arquivo dump Java. Essas informações são particularmente importantes para aplicativos que são executados em contêineres Docker , pois quando os limites de recursos são configurados dentro de um contêiner, o Docker Engine depende de cgroups para cumprir as configurações. Se estiver recebendo um erro Java OutOfMemoryError porque foi definido um limite de contêiner para a quantidade de memória disponível para um aplicativo e essa alocação não for suficiente, você poderá diagnosticar esse problema no arquivo de despejo do Java. É possível localizar as informações de cgroup na seção ENVINFO

Gravando um dump Java em STDOUT ou STDERR

Agora é possível gravar um arquivo de dump Java para STDOUT ou STDERR usando a opção da linha de comandos -Xdump

Suporte melhorado para coleta de lixo sem pausa

O modo scavenge simultâneo agora é suportado nas plataformas a seguir:

Linux no IBM POWER LE
AIX

Atualização de serviço 5, pacote de correção 35

O fix pack 35 inclui as seguintes atualizações:

Suporte para a nova era japonesa: O suporte é adicionado para o novo nome da era, Reiwa. Para obter mais informações sobre as mudanças, consulte Mudanças da era em japonês para o IBM SDK, Java Technology Edition
Suporte para mais versões do sistema operacional: Foi incluído suporte para o Red Hat Enterprise Linux (RHEL) versão 8 e Windows Server 2019. Para listas de sistemas operacionais suportados, consulte Ambientes suportados.
Mude para o tamanho da pilha nativa padrão no z/OS de 64 bits: O tamanho de pilha padrão para encadeamentos do sistema operacional no z/OS de 64 bits foi alterado de 384 KB para o mínimo de 1 MB. Para obter mais informações sobre essa configuração, consulte -Xmso

O fix pack 35 também inclui os novos recursos e aprimoramentos a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário do OpenJ9 :

Nova opção para ignorar ou relatar opções não reconhecidas -XX:: Por padrão, as opções da linha de comandos -XX: não reconhecidas são ignoradas, o que impede que um aplicativo falhe ao iniciar. Agora é possível usar -XX:-IgnoreUnrecognizedXXColonOptions para desativar esse comportamento, para que as opções -XX: não reconhecidas sejam relatadas. Para obter mais informações, consulte -XX:[+|-]IgnoreUnrecognizedXXColonOptions na documentação do usuário doOpenJ9.
Gravando um dump Java em STDOUT ou STDERR: Agora é possível gravar um arquivo de dump Java em STDOUT ou STDERR usando a opção da linha de comandos -Xdump Consulte Gravando em STDOUT/STDERR na documentação do usuário do OpenJ9 para obter detalhes
Melhores informações de diagnóstico para sistemas Linux que implementam grupos de controlo: Se você usar grupos de controle (cgroups) para gerenciar recursos em sistemas Linux , informações sobre CPU e limites de memória agora serão registradas em um arquivo dump Java. Essas informações são particularmente importantes para aplicativos que são executados em contêineres Docker , pois quando os limites de recursos são configurados dentro de um contêiner, o Docker Engine depende de cgroups para cumprir as configurações. Se você estiver obtendo um erro Java OutOfMemoryError porque um limite de contêiner foi configurado na quantia de memória disponível para um aplicativo e essa alocação não for suficiente, será possível diagnosticar esse problema a partir do arquivo de dump Java É possível localizar as informações de cgroup na seção ENVINFO Para a saída de amostra, consulte dump Java (ENVINFO) na documentação do usuário do OpenJ9.
Suporte melhorado para coleta de lixo sem pausa: O modo scavenge simultâneo (-Xgc:concurrentScavenge) agora é suportado no AIX e no Linux no POWER.
Nova opção OpenJ9 para evitar que uma consulta de rede seja usada para determinar o nome do host e o endereço IP: Por padrão, uma consulta de rede é usada para determinar o nome do host e o endereço IP para propósitos de resolução de problemas Para evitar que seu programa aguarde o tempo limite se um servidor de nomes não puder ser contatado, agora é possível evitar que a consulta seja executada.. Para obter mais informações, consulte -XX:[+|-]ReadIPInfoForRAS na documentação do usuário doOpenJ9.
Nova opção experimental para melhorar o desempenho dos campos observados da JVMTI: A opção ' -XX:[+|-]JITInlineWatches ( documentação do usuário OpenJ9 ) foi introduzida nesta versão. Quando ativada, a opção ativa as operações JIT experimentais que são destinadas a melhorar o desempenho dos campos JVMTI observados No momento, essa opção é compatível apenas com as plataformas x86 (Windows, macOS, e Linux).
Mude para o tamanho da pilha nativa padrão no z/OS de 64 bits: O tamanho da pilha padrão para encadeamentos do sistema operacional no z/OS de 64 bits foi alterado de 384 KB para 1 MB.. Para obter mais informações sobre essa configuração, consulte -Xmso

Atualização de serviço 5, pacote de correção 36

O fix pack 36 inclui os seguintes novos recursos e mudanças na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário do OpenJ9 :

Mudanças no número de geração de cache de classe compartilhada: Em todas as plataformas, o formato das classes armazenadas no cache de classes compartilhadas é alterado, o que faz com que a JVM crie um novo cache de classes compartilhadas, em vez de recriar ou reutilizar um cache existente. Para economizar espaço, todos os caches compartilhados existentes podem ser removidos, a menos que estejam em uso por uma liberação anterior.

Atualização de serviço 5, pacote de correção 37

O Fix Pack 37 inclui os novos recursos e mudanças a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário OpenJ9 :

Suporte de plataforma melhorado para coleta de lixo sem pausa: O suporte ao modo scavenge simultâneo agora é estendido ao z/OS e ao Linux on IBM Z.
Suporte para Transparent HugePage: A VM agora suporta a alocação de páginas muito grandes no Linux ao usar a configuração madvise . Para ativar esse recurso, especifique a opção -XX:+TransparentHugePage na linha de comandos quando você iniciar seu aplicativo
-XX:[ opção+|-]JITInlineWatches compatível com ' z/OS e ' Linux on IBM Z e ativada por padrão: Esta opção, introduzida em uma liberação anterior, ativa operações JIT experimentais que são destinadas a melhorar o desempenho de campos JVMTI observados. A opção agora é compatível com o z/OS e Linux on IBM Z, e é ativada por padrão.
Suporte para opções de OpenJDK HotSpot: A opção Hotspot -XX:OnOutOfMemoryError OpenJDK agora é suportada para compatibilidade.
Remoção da opção -Xdiagnosticscollector: Esta opção era redundante e agora foi removida

Atualização de serviço 5, pacote de correção 40

O fix pack 40 inclui as seguintes atualizações:

Implementação de JDWP substituída por OpenJDK equivalente

O JDWP é usado para depurar aplicativos Java, por exemplo, conforme mencionado em Opções padrãoe Java Virtual Machine Tool Interface na documentação do OpenJ9 . A implementação anterior do JDWP agora é substituída pelo equivalente do OpenJDK Essa mudança remove um problema com a implementação anterior e aumenta o alinhamento com o software livre. Como essas duas implementações são diferentes, as opções disponíveis também são diferentes. Essas opções não existem mais: version, src, loge trace. Essas opções são novas: launch, onthrow, onuncaught, mutf8e quiet. Para obter mais informações sobre as opções para a nova implementação JDWP, consulte a ajuda da linha de comandos:

java -agentlib:jdwp=help

O fix pack 40 também inclui os novos recursos e mudanças a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário OpenJ9 :

Configurando automaticamente um tamanho de heap inicial

A VM agora pode aprender e configurar um tamanho de heap inicial apropriado para um aplicativo como uma alternativa para um usuário dimensionar manualmente e configurar um valor -Xms . A VM registra o tamanho do heap quando o processamento de inicialização termina, gravando esses dados no cache de classes compartilhadas.. Um valor médio é configurado em algumas reinicializações, ajudando a assegurar que o valor usado para o tamanho de heap inicial seja o mais preciso possível O tamanho de heap registrado é específico para a linha de comando do aplicativo, portanto, uma sugestão diferente é armazenada para cada linha de comandos exclusiva

Para ativar esse comportamento, configure a opção -XX:+UseGCStartupHints na linha de comandos quando você iniciar seu aplicativo

Heurísticas para compactação durante GC inativo

A MV agora compacta automaticamente o heap quando determinados acionadores são atendidos durante a coleta de lixo inativa Como resultado dessa alteração, a opção -XX:[+|-]IdleTuningCompactOnIdle está obsoleta.

Mudança no comportamento de -XX:IdleTuningCompactOnIdle

A opção -XX:[+|-]IdleTuningCompactOnIdle agora não é mais eficaz quando a opção ' -XX:+IdleTuningGcOnIdle não é especificada.

Mudanças na interface interna

As interfaces internas da API de conexão são mudadas um pouco, afetando a biblioteca de classes internas do SDK e os arquivos tools.jar e healthcenter.jar

Se um aplicativo usar uma cópia privada do arquivo tools.jar de uma liberação anterior, o aplicativo poderá não conseguir usar a API de conexão nesta liberação porque as classes Java não correspondem. Em vez disso, use o arquivo tools.jar desta liberação.
Da mesma forma, o arquivo healthcenter.jar desta liberação não é compatível com liberações anteriores.

Atualização de serviço 5 fix pack 41

O fix pack 41 inclui os novos recursos e mudanças a seguir na máquina virtual Eclipse OpenJ9 , conforme descrito na documentação do usuário OpenJ9 :

A configuração automática do tamanho de heap inicial é ativada por padrão: A opção -XX:[+|-]UseGCStartupHints , que, quando ativada, ativa o aprendizado automático e a configuração de um tamanho de heap apropriado para um aplicativo, agora é ativada por padrão.
Opção para compartilhar classes anônimas da VM: Em liberações anteriores, as classes anônimas, aquelas criadas por Unsafe.defineAnonymousClass, não eram armazenadas no cache de classes compartilhadas Essas classes agora são armazenadas lá por padrão, o que significa que elas estão disponíveis para compilação antecipada (AOT), potencialmente melhorando o desempenho da inicialização. Uma nova opção, -XX:[+|-]ShareAnonymousClasses, é introduzida que permite parar as classes anônimas que estão sendo armazenadas no cache de classes compartilhadas.
Melhorias de desempenho para campos assistidos pela JVMTI no Power Systems: A opção ' -XX:[+|-]JITInlineWatches, que ativa as operações JIT para melhorar o desempenho dos campos observados do JVMTI, agora também é compatível com o AIX e Linux on Power Systems.
Linux em x86: suporte para páginas muito grandes transparentes (THP): Ao usar a configuração madvise (/sys/kernel/mm/transparent_hugepage/enabled) em Linux em sistemas x86 , o THP agora é ativado por padrão. Para desativar esse recurso, configure -XX:-TransparentHugePage na linha de comandos quando você iniciar seu aplicativo A configuração THP em outros sistemas permanece desativada por padrão quando você usa madvise, mas pode ser ativada configurando -XX:+TransparentHugePage.
Mudanças no número de geração de cache de classe compartilhada: O formato das classes armazenadas no cache de classes compartilhadas é alterado, o que faz com que a JVM crie um novo cache de classes compartilhadas em vez de recriar ou reutilizar um cache existente. Para economizar espaço, é possível remover todos os caches compartilhados existentes, a menos que eles estejam em uso por uma liberação anterior Como resultado da mudança de formato, uma coluna de camada agora aparece na saída da opção -Xshareclasses:listAllCaches Essa mudança é para apoiar um aprimoramento futuro.