Pourquoi Java 8 lambdas appelée à l'aide de invokedynamic?

La invokedynamic instruction est utilisé pour aider à la VM de déterminer la méthode de référence au moment de l'exécution au lieu de brancher au moment de la compilation.

C'est utile avec des langages dynamiques où la méthode exacte et les types d'argument ne sont pas connus jusqu'à l'exécution. Mais ce n'est pas le cas avec les lambdas de Java. Ils sont convertis en statique méthode bien définie arguments. Et cette méthode peut être appelée à l'aide de invokestatic.

Alors, quelle est la nécessité de invokedynamic pour les lambdas, surtout quand il y a un gain de performance?

  • Brian Goetz l'explique ici: wiki.jvmlangsummit.com/images/1/1e/2011_Goetz_Lambda.pdf
  • invokedynamic est pas utilisé pour appeler lambda, mais pour créer et lier un MethodHandle pour lambda du corps au site d'appel.
  • Indy est utilisée pour capturer l'lambda, pas l'invoquer.
  • Nous utilisons invokedynamic parce qu'il fournit à une amélioration de la performance, pas de dégradation des performances, sur le "évident" de la traduction des schémas. (Je ne sais pas d'où vous est venue l'idée qu'il y aurait un gain de performance, mais c'est incorrect.)
  • Il y a de test de performance stackoverflow.com/questions/19001241/...: "La ligne de fond est que le post compilation JIT, lambdas et anonyme classes effectuent de la même manière sur l'actuel Hostpot JVM implémentations".
  • les lambdas ne sont pas traduits à des méthodes statiques.
  • De référence?

InformationsquelleAutor Kshitiz Sharma | 2015-05-02
  1. 64

    Lambdas ne sont pas appelés à l'aide invokedynamic, leur représentation d'objet est créé à l'aide de invokedynamic, le réel de l'invocation est un régulier invokevirtual ou invokeinterface.

    Par exemple:

    //creates an instance of (a subclass of) Consumer 
//with invokedynamic to java.lang.invoke.LambdaMetafactory 
something(x -> System.out.println(x));   

void something(Consumer<String> consumer) {
      //invokeinterface
      consumer.accept("hello"); 
}

    Tout lambda est de devenir une instance de base de la classe ou de l'interface. Cette instance sera parfois contenir une copie des variables capturées à partir de la méthode originale et parfois un pointeur vers l'objet parent.
    Cela peut être mis en œuvre comme une classe anonyme.

    Pourquoi invokedynamic

    La réponse courte est: pour générer du code à l'exécution.

    Les responsables Java choisi de générer la mise en œuvre de la classe runtime.
    Ceci est fait en appelant java.lang.invoke.LambdaMetafactory.metafactory.
    Puisque les arguments pour cet appel (type de retour, de l'interface et les paramètres capturés) peut changer, cela nécessite invokedynamic.

    À l'aide de invokedynamic pour construire la classe anonyme dans l'exécution, permet à la JVM pour générer du bytecode de la classe runtime. Les appels suivants à la même déclaration utiliser une version mise en cache. L'autre raison d'utiliser invokedynamic est d'être en mesure de modifier la stratégie de mise en œuvre dans l'avenir sans avoir à modifier le code compilé.

    La route pas pris

    L'autre option serait le compilateur de la création d'un innerclass pour chaque lambda instanciation, l'équivalent de traduire le code ci-dessus dans:

    something(new Consumer() { 
    public void accept(x) {
       //call to a generated method in the base class
       ImplementingClass.this.lambda$1(x);

       //or repeating the code (awful as it would require generating accesors):
       System.out.println(x);
    }
);

    Cela nécessite la création de classes dans les temps de compilation et d'avoir à charge au cours de l'exécution. Le chemin de la jvm des œuvres de ces classes de résider dans le même répertoire que la classe d'origine. Et la première fois que vous exécutez l'instruction qui utilise que les lambda, que la classe anonyme devrait être chargé et initialisé.

    Sur les performances

    Le premier appel à invokedynamic de déclencher la classe anonyme génération. Puis l'opcode invokedynamic est remplacé par code que du rendement équivalent à l'écriture manuelle de la anonyme de l'instanciation.

    • De quoi dos de votre réclamation que “les appels répétés à la invokedynamic va générer plus de déchets ...” ou que l'exécution répétée de la même invokedynamic instruction crée aucun poubelle?
    • Un point d'arrêt à java.lang.invoke.MethodHandles.findStatic.
    • Il semble que vous ne comprenez pas ce que vous avez vu. Il y a beaucoup d'invocations causés par l'initialisation de la java.lang.invoke cadre, qui ne sont pas liés à votre expression lambda à tous. L'étape jusqu'à ce que i==1 et de voir combien de fois votre point d'arrêt sera frappé puis.
    • En effet. Savez-vous ce qui se passe à l'callsite? Je veux assurez-vous que le invokedynamic est pas être remplacé par quelque chose qui crée un nouvel Objet[] tableaux avant de revenir à ma réponse. Et MethodHandle.invokeExact prend un Objet[] comme paramètre.
    • S'il vous plaît, ne confondez pas la première fois, les frais généraux de le cadre avec la surcharge d'un seul invokedynamic instruction. Si vous placez une expression lambda avant de la boucle et de vérifier ensuite, vous verrez que le invokedynamic instruction dans la boucle d'appel findStatic exactement une seule fois lors de couplage sur la première invocation. Cela s'applique à tous les autres par la suite exécuté invokedynamic instructions ainsi, et c'est indiqué qu'après avoir terminé le couplage de la dynamique callsite, il restera lié à jamais. Et la méthode se charge de faire pas prendre Object[] comme paramètre.
    • Je ne suis pas. Je le promets. Et invokeExact prend un Objet[] comme paramètre.
    • Laissez-nous continuer cette discussion dans le chat.
    • Voir la documentation du paquet de java.lang.invoke: Chaque appel dynamique du site des transitions plus d'une fois de liés à liés, juste avant sa première invocation. Il n'y a aucun moyen d'annuler l'effet d'un appel à la méthode du bootstrap. Et essayer de comprendre Signature de polymorphisme avant de discuter plus loin...
    • Merci pour la clarification. Les références sont claires sur la méthode handle être capable de prendre des arguments directement à partir de la pile sans la boxe. Je vais modifier qu'une partie de mes réponses.
    • Donc l'invoquer dynamique est utilisé car il est plus souple. Il serait bon d'avoir un exemple de cas où cette flexibilité fait une différence. Certainement l'approche gagne beaucoup de points de complexité.

    InformationsquelleAutor Daniel Sperry
  2. 43

    Cerveau Goetz a expliqué les raisons pour le lambda stratégie de traduction dans l'une de ses papiers qui, malheureusement, semblent désormais indisponible. Heureusement j'ai gardé une copie:

    Stratégie de traduction

    Il y a un certain nombre de façons que nous pourrions représenter une expression lambda dans
    bytecode, telles que les centres des classes, la méthode des poignées, des proxies dynamiques, et
    les autres. Chacune de ces approches présente des avantages et des inconvénients. Dans le choix d'un
    stratégie, il y a deux objectifs antagonistes: la maximisation de la flexibilité pour
    l'avenir de l'optimisation par pas de s'engager à une stratégie spécifique, vs
    assurant la stabilité dans la classfile représentation. Nous pouvons réaliser
    deux de ces objectifs en utilisant la invokedynamic fonction de la JSR 292 à
    séparer la représentation binaire de lambda création dans le bytecode
    de la mécanique de l'évaluation de l'expression lambda au moment de l'exécution.
    Au lieu de générer du bytecode pour créer l'objet qui implémente
    l'expression lambda (comme l'appel d'un constructeur pour un intérieur
    classe), nous décrivons une recette pour la construction de la lambda, et délégué
    la construction réelle de la langue de l'exécution. Cette recette est
    codé dans la statique et la dynamique des listes d'arguments d'une invokedynamic
    de l'instruction.

    L'utilisation de invokedynamic nous permet de différer la sélection d'une traduction
    la stratégie jusqu'à l'exécution. L'exécution de la mise en œuvre est libre de choisir
    une stratégie de façon dynamique pour évaluer l'expression lambda. Le moteur d'exécution
    la mise en œuvre de choix qui est caché derrière un standard (c'est à dire, une partie de
    la plate-forme de spécification de l'API pour le lambda de la construction, de sorte que le
    statique compilateur peut émettre des appels à cette API, et JRE implémentations
    peuvent choisir leur préféré de mise en œuvre de la stratégie. Le invokedynamic
    la mécanique permettent de le faire sans les coûts de l'exécution que
    cette liaison tardive approche, autrement, pourraient imposer.

    Lorsque le compilateur rencontre une expression lambda, il est d'abord réduit
    (desugars) le corps de lambda dans une méthode dont l'argument de la liste et
    le type de retour correspond à celui de l'expression lambda, peut-être avec quelques
    des arguments supplémentaires (pour les valeurs capturées à partir de la portée lexicale, si
    tout.) Au point où l'expression lambda serait capturé,
    il génère une invokedynamic site d'appel, qui, lorsqu'il est invoqué, les retours
    une instance de l'interface fonctionnelle dont le lambda est
    converti. Ce site d'appel est appelé le lambda de l'usine pour une
    lambda. La dynamique des arguments pour le lambda de l'usine sont les valeurs
    capturée à partir de la portée lexicale. La méthode de démarrage de la lambda
    l'usine est une méthode normalisée dans le langage Java runtime library,
    appelé le lambda metafactory. La statique bootstrap arguments de capture
    informations connues sur le lambda au moment de la compilation (la fonctionnelle
    l'interface à laquelle elle sera convertie, une méthode pour la poignée
    délactosé lambda corps, de l'information quant à savoir si la SAM est de type
    serializable, etc.)

    Méthode références sont traités de la même manière que les expressions lambda,
    sauf que la plupart des références pour les méthodes ne doivent pas être délactosé dans un
    nouvelle méthode; il suffit de charger une constante de la méthode de la poignée pour la
    référencé méthode et passer à la metafactory.

    Donc, l'idée semble être de résumer la stratégie de la traduction et de ne pas s'engager à une façon particulière de faire les choses à cacher les détails. Dans l'avenir, lorsque le type de l'effacement et de l'absence de types de valeur ont été résolus et peut-être Java prend en charge la fonction de types, ils pourraient tout aussi bien y aller et modifier la stratégie pour un autre, sans causer de problèmes dans le code.

    InformationsquelleAutor Edwin Dalorzo
  3. 5

    Actuelle de Java 8 lambda mise en œuvre est un composé de décision:

      1. Compiler l'expression lambda à la méthode statique de la classe englobante; au lieu de compiler les lambdas pour séparer intérieure fichiers de classe (Scala compile de cette façon, de sorte que beaucoup de $$$ de fichiers de classe autour )
      1. Introduire une constante de la piscine: BootstrapMethods, qui encapsule la méthode statique invocation à callsite objet ( peut être mis en cache pour une utilisation ultérieure )

    Donc, pour répondre à votre question,

      1. actuel lambda mise en œuvre à l'aide de invokedynamic est un peu plus rapide que de les séparer intérieur de la classe manière, parce que pas besoin de charger ces intérieure des fichiers de classe, mais au lieu de créer l'intérieur de la classe byte[] à la volée ( pour satisfaire par exemple, la Fonction de l'interface ), et mis en cache pour une utilisation ultérieure.
      1. JVM de l'équipe peut toujours choisir de générer séparée intérieur de la classe ( par référence à la classe englobante de méthodes statiques ) des fichiers, il est flexible
    InformationsquelleAutor fjolt