Pregunta ¿Los tipos opcionales especializados (OptionalInt, OptionalDouble, etc.) realizan una asignación de montón?


Las funciones de llamada que devuelven tipos opcionales especializados tienen el costo de una mayor presión de GC cuando se usan en una ruta de código activo, en lugar de devolver un valor primitivo para indicar ausencia (Integer.MIN_VALUE, por ejemplo)?

Editar

La razón por la que no asumo que realizarían una asignación de pila como cualquier otra clase es que Optional, et al, son "clases basadas en valores", lo que parece implicar que pueden comportarse de manera diferente a las clases tradicionales detrás de la escena.


5
2017-10-21 20:09


origen


Respuestas:


¿Las funciones de llamada que devuelven tipos opcionales especializados tienen el costo de una mayor presión de GC cuando se utilizan en una ruta de código de acceso rápido?

Depende. En general el Optional los tipos son solo objetos normales, y por lo tanto se asignan a un montón. Pero bajo circunstancias específicas los compiladores JIT mayo descomponerlos en sus campos (es decir, el valor que tienen) y ponerlos en la pila.

Esto sucede si análisis de escape puede determinar que el objeto no escapa globalmente al montón.

También parece haber optimizaciones experimentales adicionales escondidas detrás de las banderas (-XX:+AggressiveUnboxing, parte de -XX:+AggressiveOpts) Según entiendo, pueden romper la garantía de identidad para Integer.valueOf(int) y por lo tanto no es totalmente compatible con las especificaciones.

Una tangente: El experimental / investigación. Compilador de Graal incluso va un paso más allá y tiene análisis parcial de escape lo que puede diferir la asignación a aquellas rutas de código donde los objetos se escapan y dejarlos en la pila cuando no lo hacen. Esto aún no forma parte de las máquinas virtuales normales y se utiliza principalmente en los lenguajes que no son Java que se ejecutan en la JVM, como JRuby y Nashorn.

Como todas estas cosas son una optimización del tiempo de ejecución, no hay garantía de que esto suceda. Por lo tanto, tendrá que medir los efectos o realizar un seguimiento de las decisiones del compilador con indicadores de diagnóstico.

La razón por la que no asumo que realizarían una asignación de pila como cualquier otra clase es que Opcional, y otros, son "clases basadas en valores"

Creo que en este momento esas propiedades están destinadas simplemente a garantizar que los objetos sean inmutables y seguros para subprocesos. No sé si alguna optimización más allá de EA hace uso de las propiedades de intercambiabilidad.

Sospecho que el lenguaje de especificación está destinado principalmente a proporcionar compatibilidad hacia adelante para tipos de valor cuando finalmente llegan a Java como parte de proyecto valhalla.

Seguir esas reglas también facilita las cosas para el análisis de escape / la asignación de la pila.


6
2017-10-21 21:33



Sí.

Estas clases se extienden Object Y por lo tanto son tipos de referencia. Tomarán un montón de espacio similar a si usó clases de contenedor disponibles previamente como Integer.

Además, estos tipos fomentan el uso de expresiones lambda, que a su vez crean nuevas instancias de tipos anónimos. Según los valores que las lambdas "cierran", puede terminar con los objetos que también hacen referencia a otros objetos, lo que tendría cierta influencia en el GC.

Por lo tanto, en los lugares en los que desearía no crear instancias de instancias de clases, boxeo / desempaquetado, etc. por motivos de rendimiento, querrá evitar estos tipos opcionales.

Actualizar

Java 8 introduce el concepto de clases basadas en valores como un paso adelante esperanzador para los "tipos de valores" de Java 10.

InfoQ: Hablemos un poco sobre la posibilidad de Opcional como un tipo de proto-valor.

Goetz: Posiblemente hubo un ligero optimismo sobre la idea de migrar un tipo de referencia Java 8 a un tipo de valor Java 10. Básicamente, hemos sentado las bases, al indicar que los desarrolladores no deben confiar en ciertas propiedades (como las comprobaciones de identidad), siendo necesariamente cierto para los tipos que pueden convertirse en tipos de valor en el futuro. Queda por verse si esta migración resulta factible en la práctica.

http://www.infoq.com/articles/Java-9-and-Beyond-Goetz-Rose-Interview

Entonces, a partir de Java 8, estas clases todavía funcionan como clases normales, pero al crear ciertas restricciones sobre ellas ahora, hay alguna esperanza de que puedan convertirse en Tipos de valores cuando Java 10 obtenga esa característica.

Suponiendo que esto ocurra, veo dos ventajas principales para convertir estos tipos en tipos de valor:

  1. Rendimiento mejorado, ya que no necesita usar espacio de almacenamiento dinámico.
  2. Los tipos de valor nunca son nulos, por lo que si tiene un campo de tipo OptionalDouble y nunca lo inicializa, no obtendrá excepciones de puntero nulo.

Tapón desvergonzado: aproveché estos atributos de los tipos de estructuras en C # para Maybe<> escribe una biblioteca que escribí


4
2017-10-21 20:18