L'operazione bytecode Java 'invokevirtual' non mantiene la coerenza per i metodi ereditati dall'oggetto

Question

Ho i seguenti codici.

public class Parent { 

    @Override 
    public int hashCode() { 
     return 0; 
    } 

} 

public class Child extends Parent { 

    public void test() { 
     this.toString(); 
     this.hashCode(); 
    } 

} 

Come si vede nei codici di cui sopra, figlio eredita toString() da Object e hashCode() da Parent. L'operazione Bytecode del test N. figlio è la seguente.

ALOAD 0: this 
INVOKEVIRTUAL Object.toString() : String 
ALOAD 0: this 
INVOKEVIRTUAL Child.hashCode() : int 
RETURN 

penso che se invokevirtual chiama Object.toString(), si dovrebbe chiamare Parent.hashCode() per la coerenza. oppure, chiamato Child.hashCode(), quindi deve essere chiamato Child.toString().

Tuttavia, invokevirtual non mantiene la coerenza se e solo se il metodo di destinazione è ereditato da Object.

Solo quel caso, metodo chiamate invokevirtual nell'oggetto. Per altri casi, il metodo invokevirtual chiama nella classe corrente.

Voglio sapere perché questo accade.

Answer 1

È corretto che il compilatore si comporti non logico. Ma l'effetto di questo codice è identico all'effetto di entrambe le varianti che hai suggerito. Quindi questo probabilmente non è un comportamento intenzionale, ma il risultato di una lunga evoluzione del codice del compilatore. Altri compilatori possono produrre codice diverso.

Answer 2

Secondo JVM specification p. 3.7:

Il compilatore non conosce la disposizione interna di un'istanza di classe. Invece, genera riferimenti simbolici ai metodi di un'istanza , che sono memorizzati nel pool costante di runtime. Questi elementi del pool costante vengono risolti in fase di esecuzione per determinare l'effettiva posizione del metodo .

significa che tutti questi simbolico Child.hashCode() sono solo costanti, che non si specifica una sorta di come JVM chiama questo metodo. Sembra, che per toString() metodo compilatore sa, che questo metodo ha la sua implementazione di base in Object classe, in modo che mette costante simbolica per Object classe nella piscina costante - questa è una sorta di ottimizzazione, il che rende compilatore per JVM:

Constant pool: 
const #2 = Method #24.#25; // java/lang/Object.toString:()Ljava/lang/String; 
... 
const #24 = class #34; // java/lang/Object 
const #25 = NameAndType #35:#36;// toString:()Ljava/lang/String; 

Answer 3

La mia teoria: toString() viene utilizzata molto frequentemente, quindi javac utilizza il comune Object.toString() per salvare voci di pool costanti.

Per esempio se il codice contiene foo.toString() and bar.toString(), la piscina contant necessita di un solo Object.toString, invece di due voci Foo.toString and Bar.toString

Javac probabilmente difficile codificato questa ottimizzazione, invece di analizzare il codice per vedere se è veramente necessario.