Как стать автором
Обновить
21
0
Всеволод @qwwdfsad

Пользователь

Отправить сообщение

А на Integer.valueOf(i) заметно хуже работает escape analysis в нетривиальных случаях, с комментария про это и началась эта ветка обсуждения :)

К сожалению, обертка не всегда подходит и иногда нужен именно тип Integer, поэтому приходится использовать new Integer(i).


Интересно, получится ли в итоге такой конструктор удалить в будущих версиях Java, не сломав существенную часть экосистемы

Проблема не только в конкретных инструкциях. Есть еще skid, который происходит из-за того, что прерывание срабатывает не мгновенно, зависимости по данным, от которых зависит глубина конвейеризации и влияние того, где находятся эти данные (L1-кэш, L2, ...).


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

Это вы фантазируете или имеются в виду какие-то конкретные результаты?

Автор, конечно, вряд ли имел это в виду, но в компиляторах полно NP-полных задач: аллокация регистров, instruction scheduling, минимизация количества барьеров памяти.


Речи о "нельзя оптимизировать код лучше", конечно, не идет, но практический (да пусть даже и экспоненциальный) алгоритм может дать мощный толчок компиляторным оптимизациям.

Скорее обчитался gvsmirnov :)

Плохо сформулировал.


В реализации это учитывается при помощи allocation fraction: если поток был создан между сборками и не успел много нааллоцировать, то он получит маленький TLAB как раз из-за того что его allocation fraction будет небольшим.

Про равномерность ответил в соседнем треде.


  1. Не пропущен, там просто опущены неинтересные детали про выбор "идти в быструю ветку или в медленную" и получился такой некрасивый переход, постараюсь как-нибудь поправить.


  2. Автоматический префетч срабатывает только когда идут последовательные обращения к памяти с фиксированной дельтой, а тут паттерн "аллокация -> произвольные действия -> следующая аллокация" и нужен префетч памяти под следующую аллокацию. Аналогичным образом можно было бы префетчить, например, итерацию по linked-list'у

В изначальной гипотезе это никак не учитывается, это самое простое приближение, которым можно воспользоваться: все TLAB заполняются равномерно.


В реализации это используется с помощью учитывания allocation fraction.

Не стоит делать такие утверждения не будучи членом команды, которая принимала design decision о необходимости inline.


1) Inline-лямбды невероятно рулят на андроиде, где без inline приходится под каждую лямбду генерировать анонимный класс, раздувая итоговый размер приложения.
2) Без inline-лямбд гораздо сложнее сделать (и возможно только более ограниченную версию) reified generics и non-local returns.
3) Конструкции с лямбдами в котлине активно используются в качестве очень приятного сахара (классический пример c lock из документации), логично было бы сделать, чтоб такой сахар компилировался в тот же байткод, что аналогичная (и более громоздкая в случае с try-finally) конструкция на джаве.
4) JIT вполне себе сносно инлайнит лямбды. Да, на эту оптимизацию нельзя полагаться; тем не менее полагаться на то, что средний разработчик умеет инлайнить лучше, чем компилятор уж тем более не стоит.
Вот бенчмарк, где JIT инлайнит и метод, и переданную в него лямбду.
5) Было бы странно, если бы решения о дизайне языке принимались только на основании того, что неспецифицированный JIT-компилятор может или не может сделать.


NB: я к дизайну языка никакого отношения не имею

Статья выглядит очень подозрительно с точки зрения осведомленности автора:


Диаграмма состояний и доказательство невозможности выглядит странно, хотя в том же комментарии в oopMark.hpp видно, что в заголовке просто не хватает места на хэшкод и указатель на поток + эпоху.


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

Это может и правда, но у автора в бенчмарке ошибка копипасты и в обоих случаях он синхронизируется на withoutIdHash


В версиях 6 и 7 это случайно генерируемое число. В версиях 8 и 9 это число, полученное на основании состояния потока

И в переводе, и в оригинале это звучит так, будто в 8 и 9 число уже неслучайное.
Оно все еще случайно, просто seed теперь thread-local (и не один), а сам генератор работает по-другому.


Ну и флаг для смены генератора конечно же есть.

В девятке должны поправить проблему со String Deduplication:
https://bugs.openjdk.java.net/browse/JDK-8158871

А почему JIT не смог в таком простом случае выкинуть лишний range check?

PrintAssembly для add
  0x000000010f02e688: sub    $0x30,%rsp         ;*synchronization entry
                                                ; - com.zaxxer.microbench.FastList2::add@-1 (line 73)

  0x000000010f02e68c: mov    0x20(%rsi),%ebx    ;*getfield elementData
                                                ; - com.zaxxer.microbench.FastList2::add@5 (line 73)

  0x000000010f02e68f: mov    0xc(%r12,%rbx,8),%r11d  ;*arraylength
                                                ; - com.zaxxer.microbench.FastList2::add@8 (line 73)
                                                ; implicit exception: dispatches to 0x000000010f02e7a5
  0x000000010f02e694: mov    0x18(%rsi),%ebp    ;*getfield size
                                                ; - com.zaxxer.microbench.FastList2::add@1 (line 73)

  0x000000010f02e697: cmp    %r11d,%ebp
  0x000000010f02e69a: jge    0x000000010f02e785  ;*if_icmpge
                                                ; - com.zaxxer.microbench.FastList2::add@9 (line 73)

  0x000000010f02e6a0: mov    %ebp,%r8d
  0x000000010f02e6a3: inc    %r8d
  0x000000010f02e6a6: mov    %r8d,0x18(%rsi)    ;*putfield size
                                                ; - com.zaxxer.microbench.FastList2::add@24 (line 74)

  0x000000010f02e6aa: cmp    %r11d,%ebp         ; Лишняя проверка
  0x000000010f02e6ad: jae    0x000000010f02e76d
  0x000000010f02e6b3: mov    0x8(%rdx),%r10d    ; implicit exception: dispatches to 0x000000010f02e7b5

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность