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

# Выполнение кода, который не оптимизируется компилятором

Этот вопрос касается того, как JVM (Java Virtual Machine) и компилятор обрабатывают код, когда стандартная оптимизация невозможна. Я разберу это подробно.

Что такое JVM оптимизация?

Java компилятор (javac) и JVM имеют разные стратегии оптимизации:

javac (Static Compiler)    → .class файл (bytecode)
         ↓
JVM (Runtime)             → JIT Compiler (Dynamic)
         ↓
Machine Code (CPU level)

Когда компилятор НЕ может оптимизировать

1. Динамические вызовы (Dynamic Dispatch)

// Компилятор НЕ знает, какой метод будет вызван
public class Animal {
    public void makeSound() {
        System.out.println("Generic sound");
    }
}

public class Dog extends Animal {
    @Override
    public void makeSound() {
        System.out.println("Woof!");
    }
}

// Код, который не оптимизируется
Animal animal = getAnimal(); // Может быть Dog или Cat
animal.makeSound(); // Какой метод вызовется?
                    // JVM решает во время выполнения (runtime)

Как это выполняется:

Runtime execution:
1. JVM смотрит на actual type объекта (через Object header)
2. Ищет метод в vtable (virtual method table)
3. Прыгает на нужный адрес в памяти
4. Выполняет код

Это медленнее, чем прямой вызов, но JVM может оптимизировать
through inlining, если видит что всегда один тип.

2. Зависимые от памяти операции

public class DataProcessor {
    // Компилятор НЕ знает, что будет в памяти
    public int sumArray(int[] array) {
        int sum = 0;
        for (int i = 0; i < array.length; i++) {
            sum += array[i]; // Array может быть изменён другим потоком!
        }
        return sum;
    }
}

Почему не оптимизируется:

• Другой поток может менять array[i] во время цикла
• Компилятор должен каждый раз читать из памяти
• Не может кэшировать значение

3. Внешние вызовы (External calls)

public class ExternalIntegration {
    // Компилятор НЕ знает, что делает external система
    public void processData(Data data) {
        logger.info("Starting");           // Внешний вызов
        externalService.process(data);    // Внешний API
        logger.info("Done");               // Внешний вызов
    }
}

Почему не оптимизируется:

• JVM не контролирует код logger'а
• Не может предсказать побочные эффекты
• Не может удалить даже если вызов "не используется"

4. Reflection

public class ReflectionExample {
    // Компилятор НЕ может оптимизировать reflection
    public Object getInstance(String className) throws Exception {
        Class<?> clazz = Class.forName(className);
        return clazz.getDeclaredConstructor().newInstance();
    }
}

Почему:

• className известен только во время выполнения
• Компилятор не знает какой класс будет загружен
• Не может сделать inlining или другие оптимизации

Как JVM выполняет такой код

Механизм 1: Interpreted Mode

Для сложного кода JVM может использовать интерпретацию:

Bytecode:     ALOAD_1, ALOAD_2, INVOKEVIRTUAL, ...
                ↓
Interpreter:  Читает bytecode
                ↓
              Выполняет на CPU

// Этот код может выполняться в interpreted mode
public void complexLogic(Data data) {
    if (data == null) throw new NullPointerException();
    
    for (Item item : data.getItems()) {
        if (item.isValid()) {
            process(item); // Dynamic call
        }
    }
}

Механизм 2: JIT Compilation (Just-In-Time)

Даже если код не полностью оптимизируется, JVM может:

1. Выполнить в interpreted mode первый раз
2. Собрать статистику (profiling)
3. Скомпилировать в машинный код с оптимизациями

Вызовы:  1-1000    → Interpreted mode + profiling
                     ↓
         > 10000    → JIT Compilation (Threshold)
                     ↓
         > 1000000  → Aggressive optimization

Пример JIT оптимизации

// Исходный код
public void printHello(Object obj) {
    if (obj instanceof String) {
        String str = (String) obj;
        System.out.println(str);
    }
}

// После 10000+ вызовов только со String'ами:
// JVM понимает, что obj ВСЕГДА String
// и компилирует без instanceof проверки:

public void printHello_Optimized(Object obj) {
    String str = (String) obj; // Убрал instanceof (eliminated)
    System.out.println(str);
}

Специальные случаи

Случай 1: Код зависит от состояния

public class Counter {
    private int count = 0;
    
    // Компилятор НЕ может оптимизировать
    public void increment() {
        count++; // Состояние может меняться
    }
    
    public int getCount() {
        return count; // Каждый раз читать из памяти
    }
}

Выполнение:

1. Прочитать count из памяти (Memory Read)
2. Инкрементировать (ALU Operation)
3. Написать обратно в память (Memory Write)

Этого нельзя оптимизировать, потому что другой
поток может читать count между операциями.

Случай 2: Многопоточный код

public class ThreadSafeCounter {
    private int count = 0;
    
    // Synchronized блокирует оптимизацию
    public synchronized void increment() {
        count++;
    }
}

Выполнение:

1. Acquire lock (Очень дорого на CPU)
2. Check if can proceed (Memory barrier)
3. Выполнить операцию
4. Release lock (Memory barrier)
5. Notify other threads

Это не может быть оптимизировано — нужна синхронизация.

Real-world пример: HashMap

public class HashMapPerformance {
    public void process() {
        Map<String, Integer> map = new HashMap<>();
        
        // Первый раз: медленно
        for (int i = 0; i < 10000; i++) {
            map.put("key" + i, i);  // Hash computation
        }
        
        // Второй раз: быстрее (JIT оптимизировал)
        for (int i = 0; i < 10000; i++) {
            map.put("key" + i, i);
        }
    }
}

Что происходит:

Первый цикл (Interpreted):
├─ String concatenation
├─ hash() вычисление
├─ Probe hash table
├─ Resize if needed
└─ Memory writes

Второй цикл (JIT Optimized):
├─ Inlining hash computation
├─ Constant folding for known sizes
├─ Speculative optimization
└─ Direct memory writes (faster)

Второй раз может быть 2-5x быстрее!

Как JVM принимает решения

Tiered Compilation

Java использует многоуровневую компиляцию:

Level 0: Interpretation (все платформы)
Level 1: C1 JIT compiler (быстрая компиляция, базовые оптимизации)
Level 2: C1 profiling (собирает статистику)
Level 3: C1 profiling (больше информации)
Level 4: C2 JIT compiler (агрессивная оптимизация)

// Контролировать JIT компиляцию:
// java -XX:+PrintCompilation -XX:+PrintInlining MyClass

public void demonstrate() {
    // Первый раз: Tier 0 (Interpretation)
    for (int i = 0; i < 100; i++) {
        hotMethod();
    }
    
    // После 1000+ вызовов: Tier 1 (C1 compilation)
    // Видит что hotMethod всегда один тип
    // Может inlined
    
    // После 10000+ вызовов: Tier 4 (C2 compilation)
    // Агрессивная оптимизация с speculative assumptions
}

Практические следствия

1. Benchmark должен "warm up"

@Benchmark
public void benchmark() {
    // НЕПРАВИЛЬНО: первый вызов всегда медленный
    for (int i = 0; i < 10; i++) {
        process();
    }
}

// ✅ Правильно (JMH делает это автоматически)
@BenchmarkMode(Mode.AverageTime)
@Fork(warmups=10, value=5)
public void correctBenchmark() {
    process();
}

2. Escape Analysis

public class EscapeAnalysis {
    // Компилятор видит что buffer НЕ выходит из метода
    public String buildString() {
        StringBuilder sb = new StringBuilder(); // Может оптимизировать!
        sb.append("Hello");
        sb.append(" ");
        sb.append("World");
        return sb.toString();
    }
    // JVM может аллоцировать на stack вместо heap!
    // Это очень быстро!
}

3. Dead Code Elimination

public class DeadCode {
    public void process() {
        int x = 10;
        int y = 20;
        int z = x + y; // z не используется
        
        System.out.println("Done");
    }
}
// JVM может полностью удалить вычисление z
// Это called "dead code elimination"

Когда код выполняется БЕЗ оптимизации

// 1. Очень сложная логика
// 2. Много условных переходов
// 3. Много внешних вызовов
// 4. Многопоточность
// 5. Reflection
// 6. Динамическая загрузка классов

В этих случаях JVM просто выполняет:

1. Читает bytecode
2. Выполняет инструкцию
3. Переходит к следующей
4. Собирает статистику
5. Когда достаточно вызовов → JIT компилирует

Заключение

Код, который не оптимизируется:

• Выполняется интерпретиром на начальных вызовах
• JVM собирает статистику (profiling)
• Через tiered compilation постепенно оптимизируется
• Некоторые части остаются неоптимизированными (синхронизация, reflection)

Это показывает глубокое понимание того, как JVM работает под капотом — важный навык для senior разработчика.