Comment sont les interfaces de java mis en œuvre à l'interne? (vtables?)

Question

C++ a l'héritage multiple. La mise en œuvre de l'héritage multiple au niveau de l'assemblage peut être assez compliqué, mais il y a de bonnes descriptions en ligne sur la façon dont cela se fait normalement (vtables, pointeur de corrections, les thunks, etc).

Java n'est pas multiple de mise en œuvre de l'héritage, mais il a de multiples héritage de l'interface, donc je ne pense pas directement à la mise en œuvre avec une vtable unique par classe peut implémenter cette. Comment java implémenter des interfaces à l'interne?

Je me rends compte que, contrairement à C++, Java Jit compilé, des morceaux de code peut être optimisé de façon différente, et différentes machines virtuelles java peut faire les choses différemment. Donc, est-il une stratégie générale que de nombreuses machines virtuelles suivre sur ce, ou personne ne sait la mise en œuvre dans une machine virtuelle java spécifique?

Aussi Jvm souvent devirtualize et en ligne les appels de méthode, auquel cas il n'y a pas vtables ou équivalent impliqué à tous, de sorte qu'il n'aurait pas de sens de demander à propos de réel les séquences de montage qui mettent en œuvre virtuelle/l'interface des appels de méthode, mais je suppose que la plupart des machines virtuelles toujours garder une sorte de représentation générale de classes autour de l'utilisation si ils n'ont pas été en mesure de devirtualize tout. Cette hypothèse est erronée? Cette représentation regarder en quelque sorte comme un C++ vtable? Si faire des interfaces de séparer les vtables et comment sont-ils liés à la classe vtables? Si oui, peut instances d'objet de plusieurs vtable des pointeurs (pour la classe/interface vtables) comme des instances de l'objet en C++? Ne les références d'un type de classe et un type d'interface pour le même objet ont toujours la même valeur binaire ou pouvez-ci diffèrent comme en C++ où ils ont besoin de pointeur de corrections?

(pour référence: cette question demande quelque chose de semblable à propos de la CLR, et il semble y avoir une bonne explication dans cet article msdn mais qui est peut-être obsolète maintenant. Je n'ai pas été en mesure de trouver quelque chose de semblable pour Java.)

Edit:

• Je veux dire "met en œuvre", dans le sens de "Comment le compilateur GCC mettre en œuvre entier en plus de la fonction / appelle / etc", pas dans le sens de "Java de la classe ArrayList implémente la Liste de l'interface".
• Je suis conscient de la façon dont cela fonctionne à la JVM du bytecode niveau, ce que je veux savoir, c'est quel type de code et structures de données sont générées par la JVM après qu'il est terminé le chargement des fichiers de classe et de la compilation du bytecode.

Answer 1

La principale caractéristique de la JVM HotSpot est inline mise en cache. Cela ne signifie donc pas que l'objectif de la méthode est inline, mais signifie qu'une hypothèse est mis dans l'équipe de code que chaque appel à la méthode d'interface ou virtuelle cible la même mise en œuvre (c'est à dire que le site d'appel est monomorphe). Dans ce cas, un case est compilé en code machine si l'hypothèse tient réellement (c'est à dire si le type de l'objet cible est le même que c'était la dernière fois), puis de transférer le contrôle de directement à la cible méthode, pas de tables virtuelles impliqués à tous. Si l'assertion échoue, une tentative peut être faite à convertir cette megamorphic site d'appel (c'est à dire avec plusieurs types possibles); si cela ne marche pas (ou si c'est le premier appel), habitué de longue haleine recherche est effectuée, à l'aide de vtables (pour les méthodes virtuelles) et itables (pour les interfaces).

Edit: Le Hotspot Wiki a plus de détails sur la vtable et itable talons. Dans le polymorphe cas, il met toujours une ligne de cache de la version sur le site d'appel. Toutefois, le code est en réalité un stub qui effectue une recherche dans une vtable, ou un itable. Il y a une vtable de stub pour chaque vtable décalage (0, 1, 2, ...). Les appels d'Interface ajouter un linéaire de recherche sur un tableau de itables avant d'examiner les itable (si présente) à l'offset.