Есть ли оптимизатор байт-кода Java, который удаляет бесполезные gotos?

Проблема: У меня есть метод, который компилирует более 8000 байт байт-кода Java. У HotSpot есть волшебный предел, который делает JIT не ударом для методов, которые превышают 8000 байт. (Да, разумно иметь огромный метод. Это цикл токенатора.) Метод находится в библиотеке, и я не хочу, чтобы пользователям библиотеки приходилось настраивать HotSpot для деактивации магического предела.

Наблюдение. Декомпиляция байт-кода показывает, что Eclipse Java Compiler генерирует много бессмысленных gotos. (javac еще хуже). То есть есть gotos, которые доступны только от прыжков. Очевидно, что прыжок, прыгающий на goto, должен вместо этого прыгать прямо там, где прыжки goto и goto должны быть устранены.

Вопрос: Есть ли оптимизатор байт-кода для файлов классов Java 5, который выравнивает бессмысленные цепи прыжков, а затем удаляет ненужные gotos?

Изменить: Я имею в виду такие шаблоны, как:

8698:   goto    8548
8701:   goto    0

Очевидно, что второй goto может быть достигнут только прыжком до 8701, который также может быть прямым прыжком в 0.

Во втором исследовании этот сомнительный шаблон более распространен:

4257:   if_icmpne   4263
4260:   goto    8704
4263:   aload_0

Если, очевидно, хотелось бы, чтобы компилятор изменил "не равное" сравнение на "равное" сравнение, перешел на 8704 и исключил goto.

Ответ 1

Я чувствую твою боль. Мне пришлось написать синтаксический анализатор, который имел около 5 кколов if (str.equals(...)) кода. Я ворвался в несколько методов по строкам parse1, parse2 и т.д. Если parse1 не привел к анализу ответа, был вызван parse2 и т.д. Это не обязательно лучшие практики, но он делает то, что вам нужно.

Ответ 2

Один метод компиляции более 8000 байт? Кто-нибудь понимает этот код? Можно ли проверить? Попробуйте разделить его на несколько (частных?) Методов со значимыми именами вместо того, чтобы помогать оптимизатору!

ОК, возможно, есть случаи законных больших методов. Но, извините, в этом вопросе нет намеков.

Ответ 3

Разве это имеет значение, если вы не компилируете с помощью отладочных символов (т.е. флаг -g в javac)? Это может привести к тому, что метод будет ниже магического предела.

Ответ 4

Невозможно было бы реорганизовать метод в подтемы? Современная JIT встраивает эти вызовы.

Ответ 5

Если это петля токенизатора, было бы лучше сделать это с помощью набора данных с набором данных и небольшим отражением по мере необходимости?

Таким образом, вы сохраните совпадения маркеров в структуре, которая сопоставляет их с данными об этом синтаксисе токенов и методах, реализующих связанные функции. Поиск может быть оптимизирован по структуре, и вы избегаете большой петли.

Это указывает на необходимость синхронизации данных и реализации, но вы можете генерировать данные из вашей кодовой базы с помощью doclet или, возможно, аннотации.

Не зная точно, что делает ваш большой метод, мы ограничены тем, что пытаемся оптимизировать его, как лучше всего (и это, по-видимому, невозможно).

Ответ 6

увеличивается ли ваша производительность, если вы запускаете сократитель/обфускатор байт-кода в вашем классе? например, yguard, proguard,...

возможно, вы можете написать postprocessor файла класса, используя asm, потому что ваш случай использования настолько специфичен.

даже если вы удалите все бессмысленные gotos, это приведет вас под магический предел?

Ответ 7

Список библиотек байт-кода упоминает BCEL и ASM, о котором я раньше слышал, и многие другие делали разные вещи.