openjdk.ruOpenJDK на русском

JEP 210: LambdaForm Reduction and Caching

Сокращение числа создаваемых LambdaForm и их кэширование

АвторChristian Thalinger
ОтветственныйVladimir Ivanov
ТипFeature
ОбластьImplementation
СтатусClosed / Delivered
Выпуск8u40
Компонентcore-libs / java.lang.invoke
Обсуждениеhotspot dash compiler dash dev at openjdk dot java dot net
ТрудоёмкостьM
ДлительностьM
РецензентыBrian Goetz, Mikael Vidstedt
ОдобренMikael Vidstedt
Создан2014/06/12 14:33
Обновлён2015/02/27 18:49
Задача8046703

Аннотация

Сократить создание LambdaForm и использовать кэширование, чтобы повысить производительность динамических языков.

Цели

Значительно сократить потребление памяти, сохранив текущие показатели пиковой производительности.

Мотивация

Многие преобразования method handle (например, MethodHandles::filterReturnValue) создают много новых экземпляров LambdaForm для каждого преобразованного method handle. Из-за этого приложения, интенсивно использующие method handle, потребляют слишком много памяти.

Описание

Текущая реализация method handle создаёт экземпляры LambdaForm слишком активно. Предлагаемый подход состоит из двух частей: использовать общие экземпляры LambdaForm и их байт-код для похожих преобразований и кэшировать lambda form для разных комбинаторов отдельно для каждого базового типа (см. MethodTypeForm.lambdaForms).

Тестирование

Существующие тесты хорошо покрывают функциональность. Желательны также несколько целевых тестов (т. е. тестов методом белого ящика, проверяющих, что совместное использование действительно происходит в разных случаях).

Существующие тесты:

  • jdk/test/java/{lang/invoke,util/stream}
  • тесты mlvm
  • модульные тесты Nashorn
  • ECMA test262
  • бенчмарки Octane

Режимы тестирования:

  • конфигурация по умолчанию: без флагов
  • проверки assert: -ea -esa
  • интерпретируемые и скомпилированные LF: -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD={0,30}.

Риски и допущения

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

Влияние

Изменения сосредоточены в Java-части реализации method handle (т. е. в пакетах java.lang.invoke и sun.invoke). На тех, кто не использует method handle, изменения не влияют. Новые API добавляться не будут, существующие API не изменятся.