Как заставить Scala или Java JVM удалить ветвление, если во время выполнения условие одинаковое?

Что вы можете сделать

Если значение является константой, отметьте его static final. Это также защитит вас от случайных изменений. Если вам нужно, чтобы переменная была для каждого экземпляра (например, задана в конструкторе), просто сделайте это final. JIT также сможет использовать эту информацию.

Но JIT — не единственный компилятор, способный использовать эту информацию.
Допустим, у вас есть следующий Java-код:

class A{
    static final boolean DEBUG = false;
    void a(){
        if (DEBUG){
            System.out.println("Hello World");
        }
    }
}

и вы посмотрите на байт-код, сгенерированный javac (с использованием javap -c A.class), он будет выглядеть примерно так:

Compiled from "A.java"
class A {
  static final boolean DEBUG;

  A();
    Code:
       0: aload_0
       1: invokespecial #3                  // Method java/lang/Object."<init>":()V
       4: return

  void a();
    Code:
       0: return
}

Как видите, javac (хотя я не знаю о компиляторе Scala) уже способен удалять некоторые ветки, происходящие из полей static final, если они инициализированы литералом. Но это также означает, что вам придется перекомпилировать все классы, используя это поле, если вы измените переменную DEBUG.

Если вы хотите избежать этого и при этом быть уверенным, что JIT оптимизирует это во время выполнения, вы можете сделать что-то вроде:

static final boolean DEBUG = initDebug();
private static boolean initDebug(){
    return DEBUG;
}

Что делает JIT

Теперь, даже если javac не может это встроить, JIT может сделать гораздо больше. Он может видеть, что переменная равна final, предположить, что она никогда не меняется, и оптимизировать ее.

Но даже если результат приходит от метода, который вызывается снова и снова и просто всегда возвращает одно и то же значение, даже если JIT не может встроить это значение, он все равно может обнаружить, что какая-то ветвь никогда не выполняется. В этом случае она обычно заменяет эту ветвь ловушкой деоптимизации (если ее необходимо вызвать, JIT деоптимизирует код и запускается заново). Это произойдет только для кода, который выполняется достаточно часто (а для другого кода вам не нужно беспокоиться, поскольку он обычно не влияет на производительность).

Но тебя это не должно волновать, если только тебе не придется

Во многих случаях то, что, по вашему мнению, важно для производительности, не имеет значения. Если вы когда-нибудь решите, что вам следует что-то оптимизировать, сначала проверьте, действительно ли это является узким местом. Для этого вы можете использовать Flamegraphs или аналогичные инструменты.

Как только вы дойдете до оптимизации фрагмента кода, сначала используйте JMH, чтобы измерить производительность без оптимизации. После выполнения оптимизации измерьте ее еще раз (с помощью JMH) и проверьте, улучшилась ли она. Если вы не видите существенного улучшения (или даже ухудшается), оптимизация, вероятно, того не стоит. Вы не знаете, какой код будет работать хорошо, и ваши оптимизации могут ухудшить производительность, поскольку они могут усложнить некоторые JIT-оптимизации или вызвать аналогичные проблемы.

При написании приложений Java не оптимизируйте производительность, если не знаете, что это проблема. JIT гарантирует, что то, что имеет отношение к производительности, хорошо оптимизировано. Не пытайтесь вмешаться в него, если вы не знаете, что часть приложения вызывает проблемы в вашем приложении, и не проверьте, действительно ли ваши «оптимизации» что-то улучшают.