кармы нету голосовать, но всё именно так. В разных JVM реализовано по-разному, где-то это глобальная страница, где-то это per thread. Вцелом такой механизм называется page polling.
То есть не так. Если рантайм хочет, чтобы все треды пошли на сейфпоинт — он делает эту страницу read-protected. В остальное время чтение возможно. JVM устанавливает свой обработчик прерываний. При чтении происходит прерывание, обработчик которого и взведет java треды на safepoint. Это такой быстрый if. То есть быстрый он тогда, когда идти на safepoint не надо, а если надо — то там и так будет пауза, потому накладные расходы, связанные с отработкой прерывания, несущественны.
Этот адрес находится на read-protected странице. Происходит прерывание, обработчик которого и взведет java треды на сейфпоинт. Это такой быстрый if. То есть быстрый он тогда, когда идти на safepoint не надо, а если надо — то там и так будет пауза, потомы накладные расходы, связанный с отработкой прерывания минимальны.
JIT не работает долго на прогретой программе (а джавы сереверные программы работают часто неделями)
JIT способен отработать изменения поведения программы и рекомпелироваться"
. Либо первое, либо второе, а одноверменно — примерно как наступление солнечного затемения.
Да, если у вас паттерн использования резко сменился (скажем если к вам вместо обычных запросов вдруг начали посылать один, весьма специфический, в надежде вас за'DDOS'ить), то вы можете что-то отыграть — но как часто это случается?
Здесь нету противоречия. JIT стартут вместе с JVM, работает в N потоков, пока не закончится очередь CompileQueue и JVM не придет в некое стабильное прогретое состояние. Компиляция одного метода занимает доли секунд, а приложение работают, часто, неделями. Если требуется рекомпиляция, то основной проигрыш от того, что во время рекомпиляции метод интерпретируется, что на порядок медленнее, но собоственно компиляция проходит быстро и безболезненно. Я как раз готовлю доклад про деоптимизации, так вот довольно сложно даже написать такой тест, чтобы проблема была ощутимо заметна.
А я, в общем, и обсуждаю в основном язык.
Мы же обсуждаем статью «JIT-компилятор оптимизирует не круто, а очень круто»? Здесь мог бы быть любой из более чем сотни языков, которые работают на JVM. Мог бы быть даже .NET + CLR — уверен, что JIT в нем работает примерно также, при этом и «убогого байткода» там нет, и других недостатков, вроде отсутствия массивов структур и контроля для лейаутом
у CPU есть кеш. 64K, как говорит нам Wikipedia. Который либо поступает в распоряжение программы, либо делится между JIT'ом и программой.
JIT не работает долго на прогретой программе (а джавы сереверные программы работают часто неделями). Реальный профиль работы CPU примерно как на слайде 23 вот этой презентации: http://www.slideshare.net/ZeroTurnaround/vladimir-ivanovjvmjitcompilationoverview-24613146 GC — да — кушает процессор — особенно concurrent, это плата на managed свойства языка, как спору AOT-JIT почти не имеет отношения.
То есть если у нас программа имеет статический профиль (а «суперчудеса» все JIT'ы демонстрируют на статическом профиле)
Ровно наоборот. Как раз статический профиль можно через PGO механизмы подать в gcc/clang и получить идеальный профиль. JIT способен отработать изменения поведения программы и рекомпелироваться. Например, если код, который был прогрет и нормально работал, вдруг начинает бросать exceptions. Кроме того, JVM перемещает скомпелированный код, что позволяет часто взаимодействующему коду находиться вместе, сокращая TLB misses. Наконец, уникальная возможность — можно прицепиться к программе, могда метод с брейкпоинтом уйдет в интерпретатор, после отключения bp обратно рекомпелируется,
1. Вы должны работать с данными без всякого полиморфизма (иначе JIT не сможет «развернуться»).
С умеренным полиморфизмом (а это 2-3 имплементора виртуальной функции) JIT справится, а не хуже AOTа, дальше — беда, как правило — для всех.
ваш сервер неплохо бы оснастить несколькими гигабайтами памяти — примерно так втрое больше, чем вам реально нужно
Это почти справедливо, но это расходы GC, а не JITа. Это другая тема. Я плохо знаком с .NЕT миром, но там есть AOT + GC. Всё тоже самое с точки зрения расхода памяти. И да, не втрое, а примерно +30% для долгоживущих объектов и в 2 раза для «молодого поколения». Это длинная тема.
Есть, правда, выход: вывести GC «за скобки». Выделить столько массивов простых типов, сколько вам нужно, работать там со смещениями — и вуаля: скорость примерно как у C/C++
Это справедливо. Работа со структурами, с массивами структур, с вложенными массивами — самое слабое место Java. Ждём десятку — arrays 2.0, value types и и.п. Но к JIT это не имеет отношения, это слабость языка. JIT в .NET прекрасно работает с массивами структур.
Есть еще одно слабое место именно JIT-a — это автовекторизация. JIT может найти возможность использовать векторные инструкции в простых паттернах, как и GCC/clang, но легко соорудить пример, с которыми ни один компилятор не справится, оптимизация «вручную» победит. AES шифрование например (по этой причине шифрование и хэширование делается интринсиками, а не компилятором).
Нету простых ответов, типа «быстрее в полтора раза», «медленнее в два» и т.п. Есть сценарии, которых бесконечно много, но можно выделить основные, типа «векторная математика, графика, работа с бд», и так далее.
Читайте и смотрите классику: вот свежий часовой доклад от человека, который задизайнил JIT компилятор хотспота в свое время: https://www.infoq.com/presentations/java-vs-c-performance
Коворкинги, как и офисы, почему-то у нас стараются разместить как можно ближе к центру. А зечем? Ведь резиденты коворкингов — это люди, которым от центра ничего не нужно. Н, по крайней мере, большой части. Метро рядом — это нужно, нормальная парковка поблизости — нужно, а вот центр города, с толпой народу и пробками — а зачем? А в Питере так и не смог найти подходящий коворкинг.
Причин-то много можно придумать. Слово поток в системном программировании часто используют в смысле stream. Пример, multiple threads accessing a message stream.
Мне кажется, что правильно подмечено, что работа над перформансом не начинается с подбора флажков хотспота, и не с понимания внутренностей jvm. Перформанс начинается с правильного выбора алгоритмов и структур данных, а это не относится к языку. В .net и в unmanaged языках побольше степеней свободы в выборе структур данных (java приблизится к решению этой проблемы к 10ке, когда value types допишут).
Тем, кто приходят на доклады про jvm performance, стоит помнить, что понимание внутренностей vm может помочь выжать последние несколько процентов с java приложений, в некоторых редких случаях — починить некие паталогические проблемы, но для большинства задач хватит перформанса со всеми настройками по умолчанию, лишь бы код был написан разумно.
Да и вообще, перформанс волнует небольшое количество разработчиков в процентном отношении, чаще людей волнует функциональность их приложения, то простота и корректность написания той функциональности, которую требует заказчик.
И не менее познавательная лекция Пола Сансоса на том же JVMLS о том, какой функционал из unsafe будет доступен через VarHandles, а какой — нет. См табличку 3:20
По поводу холивара про unsafe — основные притензии были в том, что хакрывая s.m.Unsafe, замену не подготовили. Да, когда-то будет varhandles, но, очевидно, очень не скоро. Unsafe использовали там, где небыло нормального api, он и сейчас не появился. При отсутсвии замены unsafe просто будет торпедироваться переход на следущие версии. Хотя в 9-ке unsafe останется, хоть и под флажком.
Вот один из известнийших примеров с Linux Kernel mail list marc.info/?l=linux-kernel&m=137390362508794&w=2
Даже не вникая в суть дискуссии, понятно, что если дошло до F-word, то конфликт имеется.
Как решать проблемы? Как и любые другие ссоры в жизни. Если люди работают в одной компании, то менеджмент способствует улаживанию конфликта, а если в разных — то как-то сами справляются.
Ссоры и недопонимание возникают чаще в распределенных командах, где накладываются невозможность поговорить лично, разница культур, разница во времени, степень владения английским языком. Можно поискать примеры для каждой из перечисленных причин.
Мой рассказ как это нужно делать не возымел тогда успеха.
Вот у Вас отличный пример того, что неправильно построенный процесс привел к неприятию его членами команды. С внедрением QR проецсса часто бывает, что если на первый раз «не пошло», то второго шанса не дают.
Суть не в том, чтобы найти оптимальные правила для всех, ибо таких не существует. Правила варьируются в зависимости от характера проекта, состава команды и т п. Но есть общие вопросы, которые надо задать, обсудить и прийти к решению при внедрении QR. Вот эти вопросы я и попытался перечислить.
Какой-то детский пост, складывается впечатление, что автор пришел в компанию, впервые увидел CR, услышал про достоинства процесса, и с радостью об этом говорит. Я участвовал во внедрении CR в двух распределенных командах, которые ранее не делали CR. То, что делать CR нужно — всем понятно, однако подводных камней хватает. Вот типичные проблемы, которые приходится решать:
1. Сколько времени ждать CR? Можно ли считать молчание (24, 48, 72 часа) знаком согласия? Как длительное отсутствие ответа ревьюеров соотносится со срочностью проекта?
2. Кто назначает ревьюера? Автор, техлид, менеджер, или добровольцы сами вызываются? Кто может быть ревьюером? Сколько ревьюеров нужно?
3. Как искать ревью ретроспективно? Это очень нужно для суппорта.
4. Что именно проверяется в ревью? На сколько ревьюер полагается на «доказательства» корректности, представленные автором?
5. Как убедить начальство во временных затратах на CR?
6. Как избежать негативных и перегретых обсуждений во время CR? Примеров крупных ссор, начавшихся с CR, немало.
7. Нередко при CR выясняется, что до написания кода следовало бы сделать design review. Надо найти баланс, какие изменения кода требуют design review, чтобы избежать переделок кода после непройденного CR.
Если тема покажется интересной community, то можно подготовить пост на эту тему
Почитал первоисточник и понял, что я спутал EULA к XP с более поздними EULA, которые запрещают модификации, которые обходят ограничения.
Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. For more information, see www.microsoft.com/licensing/userights.
Но для XP все проще, там можно, там даже не запрещено хачить винду с целью обхода регистрации.
Java, конечно, не самый компактный язык. В определенных случаях поможет краткость лямбд.
часто не столько в фичах сколько в брендах
Я не так понял исходное утверждение, думал, вы про версии апдейтов.
в C++,Python и т.д. мире то же есть разные компиляторы и интерпретаторы но они все стараются по максимуму реализовать платформу
Вот тут все строго: или реализуешь платформу на 100%, или это не java. TCK все должны проходить.
Последный параграф не понял совсем. Если код с JNI — то да, а иначе — не понимаю. В чем плюс? Имхо, в разделении семантики и реального кода, исполняющего программу, что свойственно JIT системам.
у меня только одна претензия — невозможность передать функцию как аргумент
Functional interface — наиболее подходящий эквивалент.
И потом у меня в списках пакетов есть куча JRE,JDK разных, вся эта мешанина — мешает.
Потому что разным пользователям нужны разные версии, и потому, что платформа развивается.
Потом — память, ещё ни одно приложение на Java не кушала меньше 500 мегабайт
Для эффективной работы системы с автоматической сборкой мусора нужно «пространство для маневра». А мусора — много, это особенность языка. Нет, можно писать код так, чтобы вообще выйти на некое плато и не порождать объекты, но это уже будет не совсем java-программа
Этот адрес находится на read-protected странице. Происходит прерывание, обработчик которого и взведет java треды на сейфпоинт. Это такой быстрый if. То есть быстрый он тогда, когда идти на safepoint не надо, а если надо — то там и так будет пауза, потомы накладные расходы, связанный с отработкой прерывания минимальны.
Здесь нету противоречия. JIT стартут вместе с JVM, работает в N потоков, пока не закончится очередь CompileQueue и JVM не придет в некое стабильное прогретое состояние. Компиляция одного метода занимает доли секунд, а приложение работают, часто, неделями. Если требуется рекомпиляция, то основной проигрыш от того, что во время рекомпиляции метод интерпретируется, что на порядок медленнее, но собоственно компиляция проходит быстро и безболезненно. Я как раз готовлю доклад про деоптимизации, так вот довольно сложно даже написать такой тест, чтобы проблема была ощутимо заметна.
Мы же обсуждаем статью «JIT-компилятор оптимизирует не круто, а очень круто»? Здесь мог бы быть любой из более чем сотни языков, которые работают на JVM. Мог бы быть даже .NET + CLR — уверен, что JIT в нем работает примерно также, при этом и «убогого байткода» там нет, и других недостатков, вроде отсутствия массивов структур и контроля для лейаутом
JIT не работает долго на прогретой программе (а джавы сереверные программы работают часто неделями). Реальный профиль работы CPU примерно как на слайде 23 вот этой презентации: http://www.slideshare.net/ZeroTurnaround/vladimir-ivanovjvmjitcompilationoverview-24613146 GC — да — кушает процессор — особенно concurrent, это плата на managed свойства языка, как спору AOT-JIT почти не имеет отношения.
Ровно наоборот. Как раз статический профиль можно через PGO механизмы подать в gcc/clang и получить идеальный профиль. JIT способен отработать изменения поведения программы и рекомпелироваться. Например, если код, который был прогрет и нормально работал, вдруг начинает бросать exceptions. Кроме того, JVM перемещает скомпелированный код, что позволяет часто взаимодействующему коду находиться вместе, сокращая TLB misses. Наконец, уникальная возможность — можно прицепиться к программе, могда метод с брейкпоинтом уйдет в интерпретатор, после отключения bp обратно рекомпелируется,
С умеренным полиморфизмом (а это 2-3 имплементора виртуальной функции) JIT справится, а не хуже AOTа, дальше — беда, как правило — для всех.
Это почти справедливо, но это расходы GC, а не JITа. Это другая тема. Я плохо знаком с .NЕT миром, но там есть AOT + GC. Всё тоже самое с точки зрения расхода памяти. И да, не втрое, а примерно +30% для долгоживущих объектов и в 2 раза для «молодого поколения». Это длинная тема.
Это справедливо. Работа со структурами, с массивами структур, с вложенными массивами — самое слабое место Java. Ждём десятку — arrays 2.0, value types и и.п. Но к JIT это не имеет отношения, это слабость языка. JIT в .NET прекрасно работает с массивами структур.
Есть еще одно слабое место именно JIT-a — это автовекторизация. JIT может найти возможность использовать векторные инструкции в простых паттернах, как и GCC/clang, но легко соорудить пример, с которыми ни один компилятор не справится, оптимизация «вручную» победит. AES шифрование например (по этой причине шифрование и хэширование делается интринсиками, а не компилятором).
Читайте и смотрите классику: вот свежий часовой доклад от человека, который задизайнил JIT компилятор хотспота в свое время: https://www.infoq.com/presentations/java-vs-c-performance
Тем, кто приходят на доклады про jvm performance, стоит помнить, что понимание внутренностей vm может помочь выжать последние несколько процентов с java приложений, в некоторых редких случаях — починить некие паталогические проблемы, но для большинства задач хватит перформанса со всеми настройками по умолчанию, лишь бы код был написан разумно.
Да и вообще, перформанс волнует небольшое количество разработчиков в процентном отношении, чаще людей волнует функциональность их приложения, то простота и корректность написания той функциональности, которую требует заказчик.
Поправьте опечатки: LVM -> LLVM, Java C -> javac
marc.info/?l=linux-kernel&m=137390362508794&w=2
Даже не вникая в суть дискуссии, понятно, что если дошло до F-word, то конфликт имеется.
Как решать проблемы? Как и любые другие ссоры в жизни. Если люди работают в одной компании, то менеджмент способствует улаживанию конфликта, а если в разных — то как-то сами справляются.
Ссоры и недопонимание возникают чаще в распределенных командах, где накладываются невозможность поговорить лично, разница культур, разница во времени, степень владения английским языком. Можно поискать примеры для каждой из перечисленных причин.
Вот у Вас отличный пример того, что неправильно построенный процесс привел к неприятию его членами команды. С внедрением QR проецсса часто бывает, что если на первый раз «не пошло», то второго шанса не дают.
1. Сколько времени ждать CR? Можно ли считать молчание (24, 48, 72 часа) знаком согласия? Как длительное отсутствие ответа ревьюеров соотносится со срочностью проекта?
2. Кто назначает ревьюера? Автор, техлид, менеджер, или добровольцы сами вызываются? Кто может быть ревьюером? Сколько ревьюеров нужно?
3. Как искать ревью ретроспективно? Это очень нужно для суппорта.
4. Что именно проверяется в ревью? На сколько ревьюер полагается на «доказательства» корректности, представленные автором?
5. Как убедить начальство во временных затратах на CR?
6. Как избежать негативных и перегретых обсуждений во время CR? Примеров крупных ссор, начавшихся с CR, немало.
7. Нередко при CR выясняется, что до написания кода следовало бы сделать design review. Надо найти баланс, какие изменения кода требуют design review, чтобы избежать переделок кода после непройденного CR.
Если тема покажется интересной community, то можно подготовить пост на эту тему
Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. For more information, see www.microsoft.com/licensing/userights.
Но для XP все проще, там можно, там даже не запрещено хачить винду с целью обхода регистрации.
Java, конечно, не самый компактный язык. В определенных случаях поможет краткость лямбд.
Я не так понял исходное утверждение, думал, вы про версии апдейтов.
Вот тут все строго: или реализуешь платформу на 100%, или это не java. TCK все должны проходить.
Последный параграф не понял совсем. Если код с JNI — то да, а иначе — не понимаю. В чем плюс? Имхо, в разделении семантики и реального кода, исполняющего программу, что свойственно JIT системам.
Functional interface — наиболее подходящий эквивалент.
Потому что разным пользователям нужны разные версии, и потому, что платформа развивается.
Для эффективной работы системы с автоматической сборкой мусора нужно «пространство для маневра». А мусора — много, это особенность языка. Нет, можно писать код так, чтобы вообще выйти на некое плато и не порождать объекты, но это уже будет не совсем java-программа