Java байткод iconst_0 iadd последовательность

Question

Вот тест для развлечения с тройной оператор:

public int so(final int a) { 
    int r = (int) System.currentTimeMillis(); 
    r += a == 2 ? 1 : 0; 
    return r; 
} 

Вот байткодом производства:

public int doIt(int); 
    Code: 
    0: invokestatic #2; //Method java/lang/System.currentTimeMillis:()J 
    3: l2i 
    4: istore_2 
    5: iload_2 
    6: iload_1 
    7: iconst_2 
    8: if_icmpne  15 
    11: iconst_1 
    12: goto 16 
    15: iconst_0 
    16: iadd 
    17: istore_2 
    18: iload_2 
    19: ireturn 

Я был немного удивлен, увидев, что она не устранила «else» для «+ 0». Я еще ожидал этого:

public int doIt(int); 
    Code: 
    0: invokestatic #2; //Method java/lang/System.currentTimeMillis:()J 
    3: l2i 
    4: istore_2 
    5: iload_1 
    6: iconst_2 
    7: if_icmpne  13 
    10: iinc 2, 1 
    13: iload_2 
    14: ireturn 

Так вот идет мой вопрос: делает спецификации санкционирует:

goto ... 
iconst_0 

последовательность, потому что я использовал тройной оператор, или это просто компилятор thinggy?

Очевидно, что этот вопрос не касается релевантности написания «r + = ...? 1: 0 '. Но я удивлен, потому что в других случаях компилятор делает некоторую оптимизацию, в то время как здесь он не делает никакой оптимизации.

Может ли Java-компилятор, производящий вариант 2, быть действительным Java-компилятором (в случае, если я не применил свой пример, но дело в том, что в создаваемом коде есть ненужное добавление 0 и ненужное goto компилятор, удаляющий это, все еще является допустимым компилятором .java)?

Answer 1

Sun Javac сам по себе не выполняет никаких оптимизаций, поскольку они оставлены для виртуальной машины HotSpot. Таким образом, он производит первый байт-код.

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

Если такая оптимизация необходима для виртуальных машин, у которых нет JIT (например, устройств Android), существуют такие инструменты, как Proguard, которые выполняют оптимизацию на уровне байт-кода.

Answer 2

Следует иметь в виду, что javac (код исходного кода Java для байтового кода) не оптимизирующий компилятор. На самом деле он относительно прост в генерации кода и только производит самую прямолинейную реализацию байтового кода любого исходного кода.

Это полностью по дизайну. Таким образом, JVM, отвечающий за все реальные оптимизации, имеет максимальный объем информации, доступной для принятия своих решений. В этом конкретном случае может быть неясно, как эта информация может принести пользу компилятору JIT, но из-за характера оптимизации, которую делает HotSpot, например, каждый бит информации может помочь.

Например, может быть некоторое интеллектуальное совпадение шаблонов, которое распознает общие фрагменты кода и реализует их в высоко оптимизированной версии. Теперь, еслипопытался сделать некоторую оптимизацию, то эти шаблоны могут быть намного сложнее обнаружить.