Java - Optimisation de type SAM

Question

Un working document décrivant l'état de Project Lambda mentionne les types SAM (méthode abstraite unique). Autant que je sache, la proposition lambda actuelle n'affecte pas l'exécution juste le compilateur en rendant possible la conversion automatique des expressions lambda à ces types.

Je pense que dans des circonstances idéales, les instances de types SAM pourraient être représentées en interne par des pointeurs de fonction. Par conséquent, la machine virtuelle Java peut éviter l'allocation de mémoire pour ces instances.

Je me demande si les machines virtuelles modernes sont capables de fournir une telle optimisation.

Answer 1

@ Tamás Vous devriez avoir lu cette liste mailing poste Brian Goetz:

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

Fondamentalement, abstraction lambda actuellement implémenté utilisant objets. Cependant, il a été conçu pour permettre des réalisations alternatives de lambdas, qui seraient "plus petites" que les instances de classes.

Vous pouvez considérer la situation comme similaire à l'autoboxing - les entiers sont encadrés dans Integer, mais ont une représentation "plus petite" (comme ints).

Actuellement, lambdas doit être encadré à des instances de types SAM, b/c la JVM n'a actuellement aucun moyen de représenter un lambda avec une construction plus petite. À l'avenir, il pourrait y avoir une nouvelle norme JVM qui inclurait des «fonctions primitives» qui pourraient représenter les lambdas autrement que comme des objets. Donc, pour répondre à votre question, le type d'optimisation que vous proposez ci-dessus est peut-être possible, mais cela viendrait probablement du travail post-Java 8 sur les «fonctions primitives» plutôt que sur une fonctionnalité spécifique à l'implémentation.

Answer 2

Il n'y a rien de difficile à convertir des classes de méthode unique en pointeurs de fonction, mais il vous manque une chose: les expressions lambda ne sont pas simplement des fonctions, elles sont fermetures. La différence est que les fermetures peuvent capturer des variables externes. Considérons par exemple suivant en pseudo Java:

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

... 

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

Dans cet exemple, la fonction lambda, produite par l'appel à makeAdder(), fait référence à la variable qui a été définie en dehors de ce lambda. C'est pourquoi on l'appelle "fermetures" - elles sont "fermées" sur leurs variables libres (dans ce cas - sur startNumber). Pour gérer de telles situations, les fermetures doivent contenir à la fois un pointeur vers une fonction et un pointeur vers son environnement . Donc, vous obtenez une structure de données qui a une méthode et au moins une variable. Mais n'est-ce pas une définition d'un objet dans OOP? Alors, quelle est la raison de créer un nouveau type d'objets si vous pouvez en faire une instance de classe anonyme?

Néanmoins, d'autres optimisations sur de telles classes anonymes peuvent être effectuées. Le document de travail que vous avez pointé mentionne certains d'entre eux, par exemple, déduire et utiliser efficacement les variables finales (bien que cela soit fait principalement pour permettre à lambdas sur JVM en principe, d'optimiser le code). Les classes anonymes produites peuvent aussi être finalisées, et la plupart des JVM ont déjà de bonnes optimisations pour les classes et les vars finaux.

D'autres améliorations peuvent également concerner des références à l'environnement - il y a des tonnes d'options là.