Recientemente he estado en detalles JVM y me encontré con un término directo a memoria . Una respuesta de @Peter Lawrey agarró mi atención.
Todo el sistema llama como la lectura y escritura de archivos de tomas de corriente y sólo utilizan memoria nativa . No pueden usar el montón.
Mis preguntas
- ¿Es esto cierto?
- Cualquier donde puedo compaginar esta afirmación?
- ¿Eso significa que cualquier llamada en
NIO, voy a utilizar directamente directo a la memoria ?
Nativo vs memoria del montón en las transferencias de socket (y llamadas al sistema)
No es cierto que la transferencia de datos desde y hacia los zócalos sólo puede utilizar la memoria nativa (no montón). Depende por completo de la implementación JVM, y puede incluso variar dentro de la misma aplicación de vez en cuando.
De hecho, es bastante fácil de escribir funciones JNI que utilizan la pila de memoria directa y copias evitar. El API JNI proporciona métodos para el acceso de copia cero a los datos en el montón de Java:
La segunda puede ser muy útil cuando se trata de matrices de bytes.
Interacciones con la recolección de basura
Estas funciones JNI pueden impedir la recolección de basura de avanzar . A menudo, es más beneficioso para hacer una copia. Esto es especialmente cierto al hacer una llamada al sistema de bloqueo (tales como la lectura de un socket TCP cuando no se sabe con certeza que el núcleo ha buffer de datos de rendimiento). En otros casos, puede ser posible procesar la matriz de forma incremental, en trozos más pequeños, para evitar puestos de largas y la necesidad de copias.
Debido a estos desafíos, la implementación actual en OpenJDK 11 no trata las transferencias de copia cero hacia y desde buffers de bytes (no directos) Montón-asignado, incluso en los casos en que se produciría ningún bloqueo en el núcleo y no habría ningún impacto en recolección de basura debido a los retrasos no acotados.
Las contraindicaciones para el uso de tampones byte directos
El uso de memoria intermedia de bytes directo con NIO tiene diferentes problemas: Estos tampones requieren algún tipo de finalización. Como resultado, el recolector de basura no puede disponer la forma más eficiente (y rápidamente) como otros objetos. En general, es prudente utilizar tampones byte directos sólo si son de larga vida (por ejemplo, asignados junto con el canal con el que se utilizan). Para buffers temporales, tampones de matriz con respaldo (o matrices naturales) son superiores mayor parte del tiempo.
La implementación OpenJDK evita este problema mediante la asociación de tampones directo con el hilo actual, de forma transparente los utiliza para las transferencias en los canales, y luego los devuelve a la memoria caché para cada subproceso para su uso futuro. De esta manera, los tampones directos no están en constante asigna y se desecha.
OpenJDK comunicados de más edad
Las funciones críticas de acceso a la sección de matriz mencionados anteriormente volver ir a Java 1.2. Si la máquina y de recolección de basura implementaciones virtuales individuales todavía hacen copias temporales es por supuesto no especificado (las interfaces han sido cuidadosamente diseñados de tal manera que para evitar copias no es necesario ponerlas en práctica). En hotspot en OpenJDK 8, estas funciones JNI no hacen una copia, pero como se explica en el artículo de Aleksey Shipilёv, el impacto en la recolección de basura varía de un colector al colector.