Ответ на вопрос

История вопроса

Введение invokedynamic в Java 7 через JSR 292 привело к появлению API MethodHandle для поддержки реализации динамических языков на JVM. Проблема заключалась в том, что MethodHandle.invoke должен был принимать любые комбинации типов аргументов и типов возврата без необходимости объявлять тысячи перегрузок. Архитекторы JVM решили это, введя концепцию методов с полиморфными сигнатурами, отмеченных внутренне аннотацией @PolymorphicSignature в пакете java.lang.invoke.

Проблема

Стандартный вызов метода в Java требует от компилятора генерировать инструкцию invokevirtual (или подобную), ссылающуюся на конкретный дескриптор метода в константном пуле, который точно соответствует задекларированной сигнатуре метода. Если бы MethodHandle.invoke был объявлен как принимающий Object... аргументы, каждое место вызова потребовало бы упаковки и выделения массива, что нарушило бы цели производительности. С другой стороны, объявление перегрузок для каждой возможной комбинации сигнатуры невозможно и бесконечно увеличивало бы файл Class.

Решение

JVM обрабатывает методы, аннотированные @PolymorphicSignature, особым образом. Когда компилятор сталкивается с вызовом такого метода, он игнорирует задекларированную сигнатуру и вместо этого генерирует инструкцию invokevirtual, дескриптор которой точно соответствует устраненным типам аргументов и типу возврата в точке вызова. Это позволяет MethodHandle.invokeExact выглядеть как принимающий (Object)Object в исходном коде, но скомпилироваться в (String)int в конкретном месте вызова. Затем JVM напрямую связывает этот вызов с точкой входа целевого метода без дополнительных затрат на адаптер.

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;

public class PolymorphicExample {
    public static void main(String[] args) throws Throwable {
        MethodHandle handle = MethodHandles.lookup()
            .findVirtual(String.class, "length", 
                MethodType.methodType(int.class));
        
        // Компилятор генерирует invokevirtual с дескриптором (String)int
        // хотя invokeExact объявлен как (Object)Object в байт-коде
        int result = (int) handle.invokeExact("hello"); 
        System.out.println(result); // Вывод: 5
    }
}

Ситуация из жизни

Описание проблемы

При создании высокопроизводительного фреймворка обработки событий для финансовых данных мы должны были направлять входящие сообщения к зарегистрированным обработчикам, используя рефлективную гибкость, но без затрат на выделение памяти. Каждый метод-обработчик имел разные сигнатуры - некоторые принимали long метки времени, другие - BigDecimal цены, что делало обобщенную диспетчеризацию сложной без упаковки примитивов.

Рассматриваемые разные решения

Динамическая генерация байт-кода заключалась в использовании ASM или ByteBuddy для генерации прокси-классов для каждой сигнатуры обработчика во время регистрации. Этот подход обеспечивал почти родную производительность после разогрева, но поглощал значительные объемы Metaspace и увеличивал время запуска приложения на несколько секунд во время загрузки классов и компиляции JIT. Он также добавлял сложности в обслуживании для отладки сгенерированного кода.

Рефлексия с методами-обработчиками использовала стандартный Method.invoke, за которым следовало unreflect для получения MethodHandle. Хотя это было проще реализовать, это накладывало затраты на упаковку для примитивных аргументов и предотвращало HotSpot от инлайн-ации через рефлективный уровень. Тестирование производительности показало, что диспетчеризация была в 10-15 раз медленнее по сравнению с прямыми вызовами, что нарушало наши требования к задержке.

Эксплуатация полиморфных сигнатур требовала тщательного приведения аргументов к ожидаемым типам перед вызовом invokeExact. Это позволяло компилятору генерировать специфические для сигнатуры инструкции invokevirtual для каждого места вызова, эффективно рассматривая MethodHandle как типизированный указатель на функцию. Компромисс заключался в строгости типизации на этапе компиляции - нам необходимо было проверять сигнатуры обработчиков во время регистрации, чтобы обеспечить безопасность типов, и код не компилировался бы в случае несовпадения сигнатур.

Выбранное решение и его причина

Мы выбрали подход с полиморфной сигнатурой в сочетании с уровнем проверки во время регистрации. Сгенерировав легковесные адаптерные лямбда-функции (с использованием LambdaMetafactory и invokedynamic), которые соответствовали точным сигнатурам MethodHandle, мы достигли производительности прямых вызовов при соблюдении безопасности типов. JVM мог инлайнить через MethodHandle к фактическому методу-обработчику, полностью устраняя затраты на диспетчеризацию.

Результат

Система обрабатывала 2,5 миллиона событий в секунду с задержкой менее микросекунды, что соответствовало производительности кода, написанного вручную для диспетчеризации. Нагрузка на GC снизилась на 98% по сравнению с прототипом на основе рефлексии, поскольку примитивные аргументы больше не требовали упаковки во время пути вызова. Решение оставалось управляемым, поскольку ошибки типов отлавливались на этапе компиляции, а не во время выполнения.

Что кандидаты часто упускают

Почему метод MethodHandle.invoke() позволяет преобразование типов, в то время как invokeExact() требует строгого соответствия сигнатуры, несмотря на то, что оба имеют полиморфные сигнатуры?

Оба метода содержат аннотацию @PolymorphicSignature, но invokeExact выполняет строгую проверку сигнатуры на уровне JVM. Когда компилятор генерирует инструкцию invokevirtual для invokeExact, он использует точные устраненные типы в месте вызова. Затем JVM проверяет, что эти типы точно соответствуют целевому MethodType. В отличие от этого, invoke (без Exact) включает логику для адаптации типов точки вызова к целевому типу с использованием адаптеров MethodHandle.asType, которые выполняют упаковку, распаковку и преобразования примитивов. Эта адаптация происходит в реализации MethodHandle, а не в месте вызова, что делает invoke более гибким, но потенциально медленнее из-за затрат на цепочку адаптеров.

Как JVM предотвращает нарушения безопасности типов, если методы с полиморфными сигнатурами позволяют произвольные дескрипторы методов?

JVM полагается на компилятор Java, чтобы обеспечить безопасность типов на уровне исходного кода. Поскольку @PolymorphicSignature ограничен классами модуля java.base (такими как MethodHandle и VarHandle), пользовательский код не может объявлять новые полиморфные методы. Компилятор разрешает полиморфные вызовы только там, где он может проверить типы аргументов в соответствии с ожидаемой сигнатурой в точке вызова. Для invokeExact компилятор вставляет неявные приведения, чтобы гарантировать, что сгенерированный дескриптор соответствует тому, что намеревался программист. JVM доверяет, что компилятор выполнил эту проверку, позволяя ему пропустить проверки дескрипторов во время выполнения, тем самым достигая нулевых затрат при сохранении безопасности через ограничения времени компиляции.

Почему методы с полиморфными сигнатурами кажутся приводимыми к типу Object в трассировках стека и отладке, но выполняются с конкретными примитивными типами?

Компилятор javac испускает атрибут @PolymorphicSignature в class файле для этих методов. Когда JVM разрешает вызов такого метода, он подставляет дескриптор из записи константного пула места вызова вместо задекларированного дескриптора. Это означает, что фактическое исполнение байт-кода использует конкретные типы (int, long и т.д.), но метаданные метода в объекте Class сохраняют задекларированную сигнатуру (обычно (Object...)Object) для рефлексивных целей. В результате трассировки стека показывают устраненную форму, потому что Throwable.fillInStackTrace использует символический дескриптор из метаданных метода, а не динамический дескриптор, используемый во время фактического вызова. Это различие вводит в заблуждение разработчиков, которые ожидают увидеть точные типы параметров в отладчиках.