Байт-код Java этого порядка и параметры в стеке

Question

В java-байт-код Почему приемник сначала вставляется в стек, а затем все параметры? Кажется, я помню, что это было связано с эффективностью.

Это верно как для вызовов методов, так и для полей настроек.

Метод вызова

class X { 

    int p(int a) { 
     //Do something 
    } 
    int main() { 
     int ret = p(1); 
    } 

} 

Основной метод компилирует:

aload_0 // Load this onto the stack 
iconst_1 // Load constant 1 onto the stack 
invokevirtual <int p(int)> from class X 

Установка поля:

class X { 
    int x; 
    int main() { 
     x = 1; 
    } 

} 

Основной метод компилирует в:

aload_0 // Load this onto the stack 
iconst_1 // Load constant 1 onto the stack 
putfield <int x> from class X 

Answer 1

толкания первого имеет преимущество в том

• целевого метода может использовать более плотные «aload0» байткода (меньше , если бы это было гораздо позже, в списке параметров и пришлось использовать параметрической версии байт-код aload. Поскольку «это» часто упоминается в методах доступа как к полю, так и к методу, это приводит к улучшению реальной плотности кода.
• Часто бывает, что каскадный метод отправляется как «foo.bar(). baz() Когда bar() возвращается, будущее «это» для .baz() волшебным образом уже в нужном месте на , если вы упорядочиваете вещи, как это было сделано на Java.

Answer 2

Вы спрашиваете, почему это толкает вообще? В обоих случаях вы получаете доступ к тому, что принадлежит экземпляру класса, поэтому this должен быть частью этого процесса.

Вы спрашиваете, почему это толкается первым? Просто соглашение Java. Я думаю, что всегда удобно иметь this, независимо от того, что может последовать.