Какие бессмысленные/раздражающие особенности байткода Java остались с древнейших времён?
==========================================================================================

 Есть ли в стандарте байткода Java какие-то совсем уж древние оставшиеся с момента рождения языка решения, которые когда-то показались разработчикам виртуальной машины хорошей идеей, но сейчас выглядит крохоборством или наоборот стрельбой из пушки по воробьям? Или вовсе что-то раздражавшее с самого начала, что до сих пор мешает эффективно использовать ресурс байткода и заставляет компиляторы городить многоэтажные костыли, лишь бы обойти проблемы неудачной реализации?  

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

(Для примера - имеется в виду что-то вроде огрызков архитектуры Intel 8086, которые вынуждены наследовать все современные x86-64 процессоры) 

 Если посмотреть в историю - то JVM создавалась в 1996 году как платформа для встраиваемой техники. Холодильники. Кофеварки. Техзадание такое было. И разумеется в саму спеку были заложены ограничения которые позволят байткоду собираться даже на очень слабых машинах. Где мало регистров и мало разрядности. И мы имеем стековую машину (наподобие калькулятора МК-60) в которой принципиально нет регистровой адресации. В отличие от платформ .Net/clr где есть более современная адаптация к процессору. Вобщем если вы заходите написать код который будет friendly к SSE/AVX регистрам - то у вас ничего не выйдет. На уровне JVM - максимальная разрядность алгебраического типа - 64 бит (знаковые). Это как мне кажется наиболее сильное ограничение. И неизвестно когда спека будет расширена. Насколько я вижу Oracle и JCP очень консервативны в этом вопросе и неохотно вносят изменения в сам байткод.