5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
В JDK invokedynamic (indy) главным образом используется для вынесения решения о том, как выглядит итоговый байткод для конкретной фичи языка за рамки трансляции в байткод javac-ом. Рантайм спрашивают по месту, выполняя нужный bootstrap method. Это позволяет:
1. Делать оптимизации в райнтаме, не меняя байткод (т.е. не требуя рекомпиляции javac-ом), а только докручивая bootstrap-методы
2. Доступаться к внутренним API самого JDK, которые открыты внутренним бутстрапам, но не сидят в public API. Коду, который эмитит javac, можно лазить только в публичный API. Indy позволяет сделать публичным только точку входа в bootstrap method.
3. Выбирать ровно тот байткод, который хорошо работает с конкретной версией рантайма, то есть то, что JIT хорошо понимает. При этом устраняется NxM проблема (N версий байткода, M версий рантайма), потому что рантайм эмитит нужный ему байткод сам.
4. Предкомпилировать и переиспользовать общий байткод, который может забустрапить несколько indy сразу. Это и фича конкретных бутстрапов, и более общая, типа сохранения результатов бутстрапов в CDS.
Сигнатурный полиморфизм — это только бонус на фоне этих достоинств.
Поэтому чем дальше в лес, тем больше JDK-овых фич будет полагаться на indy: удобство этого инструмента покрывает его недостатки. На него уже что только не опирается: и лямбды, и конкат, и методы в рекордах, и паттерн-матчинг, и ещё чёрта в ступе.
Алексей давно не забегал ни сюда, ни в соседнюю байтоперерабатывачную (
С invokedynamic я судя по всему просто неправильно воспринимал его работу. У меня сложилось ощущение, что эта история исключительно про дактайпинг, в то время как он подразумевает бутстрап сам по себе, и оттуда вытекает в лямбды и места, где ожидается потенциальное серьёзное улучшение кодгеном из base class library. Всё это теоретически можно было бы сделать - сейчас игнорируем улучшения, удобство и размер байткода, я про вопрос эквивалентности - старыми добрыми заржавевшими подходами, просто генерируя анонимный класс и его инстанс, сохраняя где-то последний (пока не смотрим дальше constant call site) и затем вызывая его метод в тех местах, где у нас в настоящее время висит invokedynamic, так?
Если мы говорим про бутстрап методы и возможность разного кодгена, то ну ээээээ почему бы нам тогда вообще .java-файлами приложения не распространять и пропускать стадию байткода на диске
Читать полностью…
ты ишешь какое-то более внятное объяснение, чем "мы можем использовать invokedynamic в байткоде, улучшать перфоманс в новых версиях jdk, при этом джаву не придется перекомпилировать, и тот же самый байткод будет работать быстрее?"
Читать полностью…
Спецы по greenplum, подскажите есть ли нормальные бенчмарки по инсертам/обновлениям через copy, pxf, gpfdist и как они измеряются при добавлении сегментов
Читать полностью…
нет, я про общий подход с аренами в любой ситуации, где тебе нужен потенциально циклический граф ссылок
Читать полностью…
https://knowyourmeme.com/memes/look-what-they-need-to-mimic-a-fraction-of-our-power
Читать полностью…
В джаве производительность должна быть сильно печальнее других языков (пока в ансейф не лезут), потому что в анменеджед языках можно просто переписывать шмат памяти по адресу -_-
Но json все равно далеко позади, хоть я и за человекочитаемые форматы
как будто бинарники более производительны с точки зрения скорости и памяти, но я не буду утверждать, потому что когда я пришёл уже так делали
Читать полностью…
в итоге получаем обратную своместимость протокола, и независимость от спринга и в целом языков
Читать полностью…
Все дальше чистое IMHO.
В моем понимании invokedynamic заменяет кучу прямых вызов методов с кастом переменных(особенно, если это Object). Плюс, можно подсунуть свой улучшенный метод, который сделали уже после компиляции.
"генерируя анонимный класс и его инстанс, сохраняя где-то последний"
Мне кажется у тебя без invokedynamic должно быть много таких классов по разный атрибутивный состав переменных
Например, String + Object один метода/класс
String + String второй метод/класс.
Если по старинке, то по идее норм как ты указал
https://www.youtube.com/watch?v=HWkVJkoo1_Q
Посмотри с 50 минуты, может чуть понятнее станет. Там как раз про invokedynamic. Если еще останутся вопросы, то Алексея тэгни, он есть в этом чате
Да, например почему нельзя улучшать перформанс invokedynamic в новых версиях jdk без перекомпиляции.
Я сейчас относительно серьезно, вопрос связан в том числе с тем, что я не до конца понимаю всю систему.
Это про то, что связные списки, деревья, графы и любые прочие неплоские структуры данных как один из способов - это в арене гонять?
Читать полностью…
Блин, ну я же про Shipilyov
Ты просто же на какой-то его доклад ссылаешься, нэд ?
Передадим ваше обращение нормальным языкам, воспроизводящим лейаут схемы и позволяющим прямую запись
Читать полностью…
Вам пруф что прямая запись куском в память быстрее разбора по типам и проставления их по отдельности?
Читать полностью…
ну мы же внутрь кафки не лезем за человекочитаемостью (надеюсь не лезем)
Читать полностью…
производительность это другой вопрос. речь было про
независимость от спринга и в целом языковЧитать полностью…
У нас подход такой был, мы берем бинарный формат (thrift, protobuf etc) и шлем в кафку сообщения в этом формате. Форматы популярные, есть для многих ЯП, и дальше просто десеарилизуем с помощью нужных инструментов
Читать полностью…