OOPs compactados na JVM

O layout de memória de uminstanceOop é simples: é apenas o cabeçalho do objeto imediatamente seguido por zero ou mais referências a campos de instância.

A representação da JVM de um cabeçalho de objeto consiste em:

Immediately after the header, there are be zero or more references to instance fields. Nesse caso, aword é uma palavra de máquina nativa, portanto, 32 bits em máquinas de 32 bits legadas e 64 bits em sistemas mais modernos.

Suponha que vamos mudar de uma arquitetura de 32 bits legada para uma máquina de 64 bits mais moderna. No início, podemos esperar um aumento imediato no desempenho. No entanto, nem sempre é o caso quando a JVM está envolvida.

The main culprit for this possible performance degradation is 64-bit object references. referências de 64 bits ocupam o dobro do espaço das referências de 32 bits, portanto, isso leva a mais consumo de memória em geral e a ciclos de GC mais frequentes. Quanto mais tempo dedicado aos ciclos do GC, menos fatias de execução da CPU para nossos encadeamentos de aplicativos.

Então, devemos voltar e usar essas arquiteturas de 32 bits novamente? Mesmo se isso fosse uma opção, não poderíamos ter mais de 4 GB de espaço de heap em espaços de processo de 32 bits sem um pouco mais de trabalho.

Como vimos anteriormente, a JVM adiciona preenchimento aos objetos para que seu tamanho seja múltiplo de 8 bytes. With these paddings, the last three bits in oops are always zero. Isso ocorre porque os números que são múltiplos de 8 sempre terminam em000 em binário.

Uma vez que a JVM já sabe que os últimos três bits são sempre zero, não há nenhum ponto em armazenar esses zeros insignificantes no heap. Em vez disso, ele assume que eles estão lá e armazena 3 outros bits mais significativos que não cabíamos em 32 bits anteriormente. Agora, temos um endereço de 32 bits com 3 zeros deslocados para a direita, então estamos compactando um ponteiro de 35 bits em um de 32 bits. This means that we can use up to 32 GB –  2³²⁺³=2³⁵=32 GB – of heap space without using 64-bit references.

Para fazer essa otimização funcionar, quando a JVM precisa encontrar um objeto na memóriait shifts the pointer to left by 3 bits (basicamente adiciona esses 3 zeros de volta ao final). Por outro lado, ao carregar um ponteiro na pilha, a JVM move o ponteiro para a direita em 3 bits para descartar os zeros adicionados anteriormente. Basically, the JVM performs a little bit more computation to save some space.  Felizmente, o deslocamento de bits é uma operação realmente trivial para a maioria das CPUs.

Para habilitar a compressãooop , podemos usar o sinalizador de atordoamento-XX:+UseCompressedOops . A compressãooop é o comportamento padrão do Java 7 em diante, sempre que o tamanho máximo de heap for menor que 32 GB. When the maximum heap size is more than 32 GB, the JVM will automatically switch off the oop compression. Portanto, a utilização de memória além de um tamanho de heap de 32 Gb precisa ser gerenciada de maneira diferente.

Também é possível usar ponteiros compactados quando os tamanhos de heap Java são maiores que 32 GB. Although the default object alignment is 8 bytes, this value is configurable using the -XX:ObjectAlignmentInBytes tuning flag. The specified value should be a power of two and must be within the range of 8 and 256.

Podemos calcular o tamanho máximo possível de heap com ponteiros compactados da seguinte maneira:

Por exemplo, quando o alinhamento do objeto é de 16 bytes, podemos usar até 64 GB de espaço de heap com ponteiros compactados.

Observe que, à medida que o valor do alinhamento aumenta, o espaço não utilizado entre os objetos também aumenta. Como resultado, podemos não obter benefícios ao usar ponteiros compactados com grandes tamanhos de heap Java.

ZGC, uma nova adição emJava 11, é um coletor de lixo de baixa latência experimental e escalável. Ele pode lidar com diferentes faixas de tamanhos de heap, mantendo as pausas do GC abaixo de 10 milissegundos. Como o ZGC precisa usar64-bit colored pointers,it does not support compressed references. Portanto, o uso de um GC de latência ultra baixa como o ZGC deve ser trocado novamente usando mais memória.