Какие бессмысленные/раздражающие особенности байткода Java остались с древнейших времён?
Есть ли в стандарте байткода Java какие-то совсем уж древние оставшиеся с момента рождения языка решения, которые когда-то показались разработчикам виртуальной машины хорошей идеей, но сейчас выглядит крохоборством или наоборот стрельбой из пушки по воробьям? Или вовсе что-то раздражавшее с самого начала, что до сих пор мешает эффективно использовать ресурс байткода и заставляет компиляторы городить многоэтажные костыли, лишь бы обойти проблемы неудачной реализации?
Речь не о внутреннем устройстве виртуальной машины, я в курсе, что с момента рождения языка там произошла куча изменений, и не о новых и старых возможностях самого языка, которые всё равно компилируются в тот же байткод. Вопрос именно про сами однобайтовые инструкции, которые кушает виртуальная машина.
(Для примера - имеется в виду что-то вроде огрызков архитектуры Intel 8086, которые вынуждены наследовать все современные x86-64 процессоры)
Bavashi, лестный комментарий, спасибо за такую веру в меня! Жаль, что не оправдаю. JVM достаточно хорошо спроектирована, чтобы много лет развиваться без серьёзных костылей. Я иногда натыкаюсь на какие-то мелочи, но недостаточные не только упоминания, но и для запоминания. Подпишусь на вопрос, если опять на что-то наткнусь, постараюсь написать ответ.
Если посмотреть в историю - то JVM создавалась в 1996 году как платформа для встраиваемой техники. Холодильники. Кофеварки. Техзадание такое было. И разумеется в саму спеку были заложены ограничения которые позволят байткоду собираться даже на очень слабых машинах. Где мало регистров и мало разрядности. И мы имеем стековую машину (наподобие калькулятора МК-60) в которой принципиально нет регистровой адресации. В отличие от платформ .Net/clr где есть более современная адаптация к процессору. Вобщем если вы заходите написать код который будет friendly к SSE/AVX регистрам - то у вас ничего не выйдет. На уровне JVM - максимальная разрядность алгебраического типа - 64 бит (знаковые). Это как мне кажется наиболее сильное ограничение. И неизвестно когда спека будет расширена. Насколько я вижу Oracle и JCP очень консервативны в этом вопросе и неохотно вносят изменения в сам байткод.
И разумеется в саму спеку были заложены ограничения которые позволят байткоду собираться даже на очень слабых машинах.
Собираться?
В отличие от платформ .Net/clr где есть более современная адаптация к процессору.
CLR тоже стековая. А вот ART и Dalvik, предназначенные для работы на устройствах с ограниченными ресурсами, наоборот регистровые.
Вобщем если вы заходите написать код который будет friendly к SSE/AVX регистрам - то у вас ничего не выйдет.
Виртуальная машина как раз для того и нужна, чтобы изолировать от железа, не должен программист на Java или C# писать код с учётом SSE/AVX. Кроме того, JIT-компилятор как раз очень хорошо использует все самые современные возможности процессоров, посмотрите во что превращается работа с массивами и найдёте там соответствующие инструкции. Наконец, с 16-й Java должен появиться Vector API для тех, кто зачем-то решил писать молотилку чисел на не очень предназначенном для этого языке.
Чет я не всё понял. Зачем байткоду вообще что-то знать про среду выполнения? Это же задача того кто поддерживает рантайм, не? На кулькуляторе будет тебе стэк-машинка, на интеле будут тебе регистры, не так?
В таком ключе ответ вообще универсальный "как напишите среду выполнения так и будет работать".
Весь мир инфо-технологий построен на абстракциях. Абстракции начинаются даже не в момент разработки. А когда обсуждается ТЗ. Но иногда эти абстракции бывают так далеки от реальности что от них отказываются в практическом использовании. Яркий пример - языки Scheme, Lisp. Хотя я люблю эти языки. Сама по себе JVM - это тоже абстракция над будущим железом. И тема этого вопроса - в той глубине раздражения которую мы можем испытывать решая вопросы разработки. В моем случае - это вопросы перформанса.
Средний
Простой
