Recolector de basura Z en Java

Hoy en día, es común que las aplicaciones respondan a miles o incluso millones de usuarios al mismo tiempo. Tales aplicaciones necesitan cantidades inconmensurables de memoria. Sin embargo, administrar toda esa memoria puede afectar fácilmente el rendimiento de la aplicación. Para superar este problema, Java 11 incluye muchas mejoras y cambios en el dominio GC (Garbage Collection) . Java 11 tiene algunas características excelentes, una es Z Garbage Collector (ZGC) . El Z Garbage Collector, también conocido como ZGC, es un recolector de basura escalable de baja latencia diseñado para cumplir los siguientes objetivos.

• Los tiempos de pausa no deben exceder los 10 ms
• Manejar montones que van desde 8 MB a 16 TB de tamaño
• Los tiempos de pausa no aumentan con el tamaño del montón o del conjunto en vivo.

En resumen, el recolector de basura Z posee las siguientes características:

1. Concurrente
2. basado en la región
3. compactación
4. Compatible con NUMA : el acceso a memoria no uniforme (NUMA) es una forma de configurar un grupo de microprocesadores en un sistema de multiprocesamiento, de modo que la memoria se pueda compartir localmente y se pueda mejorar el rendimiento y ampliar la capacidad del sistema.
5. Usando punteros de colores
6. Uso de barreras de carga

(A) Características del recolector de basura Z

•  ZGC realiza todo el trabajo costoso al mismo tiempo, sin detener la ejecución de subprocesos de la aplicación durante más de 10 ms, lo que lo hace ideal para aplicaciones que necesitan baja latencia y/o utilizan un almacenamiento dinámico muy grande (varios terabytes).
• ZGC es más flexible en la configuración de su tamaño y esquema.
• ZGC es un GC de una sola generación. También admite la compactación parcial.

(B) Comprender el recolector de basura Z

Para trabajar con Z Garbage Collector tenemos que seguir varios pasos. Debe instalar el binario JDK, que es específico para Linux/x64, compilarlo e iniciarlo. Puede usar los siguientes comandos para descargar ZGC y compilarlo en su sistema:

$ hg clone http://hg.openjdk.java.net/jdk/jdk
$ cd zgc
$ sh configure --with-jvm-features=zgc
$ make images

Después de la ejecución de los comandos dados, puede encontrar el directorio raíz de JDK en la siguiente ubicación:

g./build/linux-x86_64-normal-server-release/images/jdk 

(C) Implementación: clase básica HelloGFG 

// Java Program to Simply Create a Demo Class
 
// Importing input output libraries
import java.io.*;
 
// Main Class
class HelloGFG {
    // Main driver method
    public static void main(String[] args)
    {
        // Print statement
        System.out.println(
            "Hello to new Garbage Collector - ZGC!");
    }
}

Hello to new Garbage Collector - ZGC!

Ahora, el siguiente comando se puede usar para habilitar ZGC y usarlo:

java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC HelloGFG

Para habilitar el registro básico de GC, el usuario puede agregar la opción -Xlog:gc . El registro detallado es útil mientras se ajusta una aplicación. El usuario puede habilitarlo usando la opción -Xlog:gc* de la siguiente manera: 

java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xlog:gc* HelloGFG

El comando anterior generará todos los registros en la consola, lo que podría dificultar la búsqueda de contenido específico. El usuario puede especificar los registros que se escribirán en un archivo de la siguiente manera: 

java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xlog:gc:mylog.log* HelloGFG

(D) Montón del recolector de basura Z

ZGC divide la memoria en regiones, también llamadas ZPages. Estos pueden ser creados y destruidos dinámicamente. El montón ZGC puede tener varias apariciones de estas regiones del montón. Las regiones medianas y grandes se asignan de forma contigua. Estos también pueden tener un tamaño dinámico (a diferencia del G1 GC ), que son múltiplos de 2 MB. Estos son los grupos de tamaño de las regiones del montón:

(E) Fases del recolector de basura Z:

El ciclo GC de ZGC se divide en tres pausas. 

1.  Pausar Marcar inicio: en la primera fase, ZGC recorre el gráfico del objeto para marcar la vida o la basura del objeto. Esta fase también incluye la reasignación de datos en vivo. Esta es, con diferencia, una de las cargas de trabajo más exigentes del ciclo ZGC GC.
2. Pause Mark End: la segunda fase es donde se realiza el preprocesamiento de referencia. La descarga de clases y la selección de conjuntos de reubicación también se realizan en esta fase. También incluye la selección del conjunto de reubicación. ZGC marca las regiones que quiere compactar.
3. Pausa Reubicar Inicio: la última fase es donde ocurre el trabajo pesado de compactar el montón.

(F) Punteros de colores

Los punteros de colores son uno de los conceptos centrales de ZGC. Permite a ZGC encontrar, marcar, ubicar y reasignar los objetos. No es compatible con plataformas x32. La implementación de puntos de colores necesita el enmascaramiento de direcciones virtuales, lo que podría lograrse en el hardware, el sistema operativo o el software. El siguiente diagrama muestra el diseño del puntero de 64 bits:

Los primeros 18 bits están reservados para uso futuro. Los 42 bits pueden direccionar hasta 4 TB de espacio de direcciones. Ahora vienen los 4 bits restantes e intrigantes. Los bits Marked1 y Marked0 se utilizan para marcar objetos para la recolección de basura. Al configurar el bit único para Reasignado, se puede marcar un objeto que no apunta al conjunto de reubicación. El último bit de 1 para finalizar se relaciona con el procesamiento de referencia concurrente. Marca que un objeto solo puede ser accesible a través de un finalizador.

Como se muestra en el diagrama anterior, la referencia de objeto de 64 bits se divide de la siguiente manera:

(G) Recolector de basura Tuning Z

ZGC es un recolector de basura concurrente. Al configurar la cantidad de tiempo de CPU que debe asignarse a los subprocesos ZGC, el usuario puede controlar la frecuencia con la que se activa el GC. Puede hacerlo mediante la siguiente opción:

-XX:ConcGCThreads=<number>

Un valor más alto para la opción ConcGCThreads dejará menos tiempo de CPU para su aplicación. Por otro lado, un valor más bajo puede hacer que su aplicación tenga problemas de memoria; su aplicación podría generar más basura que la que recopila ZGC. ZGC también puede usar valores predeterminados para ConcGCThreads. Para ajustar su aplicación en este parámetro, es posible que prefiera ejecutar contra valores de prueba.

Para el ajuste ZGC avanzado, el usuario también puede habilitar páginas grandes para mejorar el rendimiento de su aplicación. Se puede hacer usando la siguiente opción: 

-XX:+UseLargePages

En lugar de habilitar páginas grandes, el usuario también puede habilitar páginas grandes transparentes usando la siguiente opción: 

-XX:+UseTransparentHugePage

La opción anterior también incluye ajustes y configuraciones adicionales, a los que se puede acceder utilizando la página wiki oficial de ZGC.

ZGC es un GC compatible con NUMA. Las aplicaciones que se ejecutan en la máquina NUMA pueden resultar en una ganancia de rendimiento notable. De forma predeterminada, la compatibilidad con NUMA está habilitada para ZGC. Sin embargo, si la JVM se da cuenta de que está vinculada a un subconjunto de la JVM, esta función se puede desactivar. Para anular la decisión de una JVM, se puede utilizar la siguiente opción: 

-XX:+UseNUMA

Conclusión:

En este artículo, vimos que ZGC tiene la intención de admitir grandes tamaños de almacenamiento dinámico con tiempos de pausa de aplicación bajos. Hemos discutido brevemente el GC escalable y de baja latencia para OpenJDK—ZGC. Es un GC experimental, que ha sido escrito desde cero. Como GC concurrente, promete una latencia máxima de menos de 10 milisegundos, que no aumenta con el tamaño del almacenamiento dinámico o los datos en vivo. Actualmente, solo funciona con Linux/x64 . Se pueden admitir más plataformas en el futuro si existe una demanda considerable para ellas.