Java: optimización del tipo SAM

Question

A working document que describe el estado de Project Lambda menciona los llamados tipos SAM (método abstracto único). Hasta donde sé, la propuesta actual de lambda no afecta el tiempo de ejecución solo al compilador al hacer posible la conversión automática de expresiones lambda a estos tipos.

Creo que, en circunstancias ideales, las instancias de tipos de SAM podrían estar representadas internamente por indicadores de función. Por lo tanto, la JVM podría evitar la asignación de memoria para estas instancias.

Me pregunto si las máquinas virtuales modernas son capaces de proporcionar dicha optimización.

Answer 1

@ Tamás Usted probablemente debería tener una lectura de esta lista de correo mensaje por Brian Goetz:

http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003877.html

Básicamente, la abstracción lambda se implementa actualmente el uso de objetos. Sin embargo, ha sido diseñado para permitir realizaciones alternativas de lambdas, que serían "más pequeñas" que las instancias de clases.

Puede pensar que la situación es similar a la del autoboxing - las entradas están encuadradas en Entero, pero tienen una representación "más pequeña" (como ints).

En la actualidad, las lambdas deben encasillarse en instancias de tipos de SAM, b/c la JVM actualmente no tiene manera de representar una lambda con una construcción más pequeña. En el futuro, puede haber un nuevo estándar JVM que incluye "funciones primitivas" que podrían representar lambdas como algo más que objetos.

Por lo tanto, para responder a su pregunta, puede ser posible el tipo de optimización que propone, pero probablemente vendrá después del trabajo posterior a Java 8 en "funciones primitivas" en lugar de ser una función específica de implementación.

Answer 2

No hay nada difícil en convertir clases de método único para los punteros a la función, pero le falta una cosa: las expresiones lambda no son solo funciones, son cierres. La diferencia es que los cierres pueden capturar variables externas. Considere siguiente ejemplo en seudo Java:

public Adder makeAdder(double startNumber) { 
    return #{ int number -> number + startNumber} 
} 

... 

int startNumber = 5; 
Adder add5 = makeAdder(startNumber); 
add5.invoke(4); // ==> 9 

En esta función ejemplo lambda, producido por la llamada a makeAdder(), se refiere a la variable que se define fuera de este lambda. Es por eso que se llama "cierres": están "cerrados" sus variables libres (en este caso, sobre el número de inicio). Para manejar tales situaciones, los cierres deben contener tanto el puntero a una función como el puntero a su entorno . Entonces, obtienes una estructura de datos que tiene un método y al menos una variable. Pero, ¿no es una definición de objeto en OOP? Entonces, ¿cuál es el motivo para crear nuevos tipos de objetos si puede convertirlos en una instancia de clase anónima?

Sin embargo, se pueden realizar algunas otras optimizaciones en clases anónimas. El documento de trabajo que usted mencionó menciona algunos de ellos, por ejemplo, inferir y usar efectivamente variables finales (aunque esto se hace principalmente para permitir el uso de lambdas en JVM en principio, no para optimizar el código). La clase anónima producida también puede finalizarse, y la mayoría de las JVM ya tienen buenas optimizaciones para los vars y las clases finales.

Otras mejoras también pueden referirse a las referencias al medio ambiente: hay muchas opciones allí.