Высокая производительность
Java
Блог компании «Maxifier Development»
Комментарии 5
+1
Спасибо за перевод. Небольшая поправка. Имелись ввиду «биморфные» вызовы, а не «биоморфные». Смысл довольно-таки сильно меняется.
+1
docs.oracle.com/javase/specs/jvms/se7/html/jvms-3.html#jvms-3.7
The operand of the invokevirtual instruction (in the example, the run-time constant pool index #4) is not the offset of the method in the class instance. The compiler does not know the internal layout of a class instance. Instead, it generates symbolic references to the methods of an instance, which are stored in the run-time constant pool. Those run-time constant pool items are resolved at run-time to determine the actual method location. The same is true for all other Java Virtual Machine instructions that access class instances.

Не следует ли из этого, что там одни раз определяется откуда вызывать метод для класса и после warmup все вызовы будут занимать одинаковое время в пределах погрешности? Что, кстати, и подтверждается результатами.

Почему у iterations такое маленькое значение в аннотациях? Что изменится, если разные ключики понадобавлять, типа -server?
0
Не следует ли из этого, что там одни раз определяется откуда вызывать метод для класса и после warmup все вызовы будут занимать одинаковое время в пределах погрешности? Что, кстати, и подтверждается результатами.


Ну это же совсем про другое.

constant pool существует в байткоде. Поскольку компилятор не знает на этапе компиляции, в какой слот таблицы виртуальных методов попадет тот или иной метод, он создает запись в constant pool-е, которая содержит имя класса или интерфейса, который нужно вызвать, и сигнатуру метода.

При загрузке класса JVM разрешает зависимости класса и создает таблицы виртуальных методов в памяти. А уже дальше случается всякая магия вроде инлайнинга и тому подобного.

Конечно, если бы разрешение метода по имени класса и сигнатуре происходило при каждом вызове, мы бы наблюдали на порядки большее среднее время.

Почему у iterations такое маленькое значение в аннотациях?


Не такое уж маленькое:

@Warmup(iterations = 5, time = 1, timeUnit = SECONDS)


это означает, что будет сделано 5 итераций прогрева, каждая по одной секунде. А за секунду можно сделать очень много вызовов метода (сотри миллионов!)

Полагаю, что этого вполне достаточно.

Что изменится, если разные ключики понадобавлять, типа -server?


Хороший вопрос. Автор пускал я так понимаю с настройками по-умолчанию (судя по этому).

На досуге попробую поиграться с другими комбинациями.
+1
Не следует ли из этого, что там одни раз определяется откуда вызывать метод для класса и после warmup все вызовы будут занимать одинаковое время в пределах погрешности? Что, кстати, и подтверждается результатами.


Ну это же совсем про другое.

constant pool существует в байткоде. Поскольку компилятор не знает на этапе компиляции, в какой слот таблицы виртуальных методов попадет тот или иной метод, он создает запись в constant pool-е, которая содержит имя класса или интерфейса, который нужно вызвать, и сигнатуру метода.

При загрузке класса JVM разрешает зависимости класса и создает таблицы виртуальных методов в памяти. А уже дальше случается всякая магия вроде инлайнинга и тому подобного.

Конечно, если бы разрешение метода по имени класса и сигнатуре происходило при каждом вызове, мы бы наблюдали на порядки большее среднее время.

Почему у iterations такое маленькое значение в аннотациях?


Ну не такое уж маленькое:

@Warmup(iterations = 5, time = 1, timeUnit = SECONDS)


это означает, что будет сделано 5 итераций прогрева, каждая по одной секунде. А за секунду можно сделать очень много вызовов метода (сотри миллионов!)

Полагаю, что этого вполне достаточно.

Что изменится, если разные ключики понадобавлять, типа -server?

Хороший вопрос. Автор пускал я так понимаю с настройками по-умолчанию (судя по этому).

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