Там не всё так просто. Когда этот тикет появился, с интринсиками дела обстояли туго, и всякие doubleToRawLongBits были реально медленными, поэтому такое изменение не имело смысла. Потом времена изменились.
Аннотированных так методов, кстати, в разы больше, чем настоящих интринсиков. Поэтому доверять этой аннотации нельзя, надо смотреть конкретно в исходники JVM (для C2 - opto/library_call.cpp)
А еще кассу нельзя просто взять и унести в другое место: контроль места регистрации в случае несовпадения данных блокирует работу и сигнализирует о нарушении.
Кажется, дело в том, что загрузка новой иконки (чтобы показать кнопку) - это I/O операция, которая может потенциально затянуться на неопределённое время (например, может потребоваться раскрутить жёсткий диск). Чтобы избежать возможных фризов пользовательского интерфейса, мы стараемся как можно больше I/O операций утаскивать в фоновые потоки. Лучше крутилка, чем всё окно подвиснет.
Это ограничивает возможности для дедупликации рантайм-представлений. Была такая инициатива condy-folding по склейке одинаковых метод-референсов (а потенциально и лямбд) в пределах класса в одну константу. Что-то заглохло оно, но может кто-то хотел бы к ней вернуться. Ну и придётся делать какое-то исключение для скрытых классов в стек-трейсах (например, показывать, если там дебаг-инфо есть), то есть уже изменения в хотспотовском рантайме.
Отличный единорог у вас, ребята. Старый блюющий мне не нравился, а новый - ну просто каваище! Третий год используем ваш перекидной календарь, представляете!
Но как связан тип char и лексический анализ исходников? Немного каша получилась, извините. В Java могло бы вообще не быть типа char, и при этом точно так же обрабатываться \u-последовательности.
В разы проще в поддержке, говорите? Знаю историю, когда весьма опытный и прошаренный программист написал серьёзный пласт логики на корутинах, затем настолько замучался их отлаживать, что выкосил их полностью, перейдя на более традиционные штуки типа CompletableFuture. Вы, конечно, можете сказать, что просто программист недостаточно умный, а умный бы всё быстро отладил. Но во-первых, это не так, а во-вторых, даже если вы гениальны и легко ловите находите любые баги в корутиновом коде просто посмотрев на него, то не факт, что тот, кто придёт после вас поддерживать этот код, будет настолько же прозорлив.
switch(calcValue()) {
case String str -> processString(str);
case 42 -> process42();
case Integer i -> processInt(i);
case Object other -> processElse(other);
}
Очень круто, что можно будет дать говорящее имя переменной в каждой ветке, а не использовать везде абстрактное v.
Там не всё так просто. Когда этот тикет появился, с интринсиками дела обстояли туго, и всякие
doubleToRawLongBitsбыли реально медленными, поэтому такое изменение не имело смысла. Потом времена изменились.Аннотированных так методов, кстати, в разы больше, чем настоящих интринсиков. Поэтому доверять этой аннотации нельзя, надо смотреть конкретно в исходники JVM (для C2 - opto/library_call.cpp)
То есть вы думаете, что я сослался на пулл-реквест, где этот код изменён на более свежий, но не глянул, что было до этого? :-)
Немного поправил статью, упомянул такую возможность. Спасибо!
Так джава - очень высокопроизводительный язык! В ней всегда выжимают проценты.
Стоит уточнить, что авторы виртуальной машины могут это сделать. Обычный пользователь JVM не имеет такой роскоши :-)
signum - тоже нетривиальная операция с условиями. Да и умножение не на константу. Заметно медленнее будет скорее всего. Но я не проверял!
Вариант интересный, но на низком уровне может быть гораздо более сложный. Вряд ли это будет быстрее, чем `0.0 - x`.
Кажется, не выкинет.
О, спасибо! Я действительно немножко оплошал и неправильно объяснил. Поправил статью.
Хороший вариант! Но отдельное условие для нуля всё равно будет.
А были попытки унести кассу? С какой целью?
Звучит не очень хорошо. Посмотрите, пожалуйста, в логах (Help|Open log in editor), может там какое-то исключение?
Кажется, дело в том, что загрузка новой иконки (чтобы показать кнопку) - это I/O операция, которая может потенциально затянуться на неопределённое время (например, может потребоваться раскрутить жёсткий диск). Чтобы избежать возможных фризов пользовательского интерфейса, мы стараемся как можно больше I/O операций утаскивать в фоновые потоки. Лучше крутилка, чем всё окно подвиснет.
Не очень понял - индусы, отвечающие на вопросы на StackOverflow, или индусы, копирующие код со StackOverflow?
Вообще в наши дни самый быстрый разработчик планеты - это GitHub CoPilot.
Это ограничивает возможности для дедупликации рантайм-представлений. Была такая инициатива condy-folding по склейке одинаковых метод-референсов (а потенциально и лямбд) в пределах класса в одну константу. Что-то заглохло оно, но может кто-то хотел бы к ней вернуться. Ну и придётся делать какое-то исключение для скрытых классов в стек-трейсах (например, показывать, если там дебаг-инфо есть), то есть уже изменения в хотспотовском рантайме.
Отличный единорог у вас, ребята. Старый блюющий мне не нравился, а новый - ну просто каваище! Третий год используем ваш перекидной календарь, представляете!
Но как связан тип char и лексический анализ исходников? Немного каша получилась, извините. В Java могло бы вообще не быть типа char, и при этом точно так же обрабатываться \u-последовательности.
В разы проще в поддержке, говорите? Знаю историю, когда весьма опытный и прошаренный программист написал серьёзный пласт логики на корутинах, затем настолько замучался их отлаживать, что выкосил их полностью, перейдя на более традиционные штуки типа CompletableFuture. Вы, конечно, можете сказать, что просто программист недостаточно умный, а умный бы всё быстро отладил. Но во-первых, это не так, а во-вторых, даже если вы гениальны и легко ловите находите любые баги в корутиновом коде просто посмотрев на него, то не факт, что тот, кто придёт после вас поддерживать этот код, будет настолько же прозорлив.
В Java 17 обещают завезти:
Очень круто, что можно будет дать говорящее имя переменной в каждой ветке, а не использовать везде абстрактное
v.