Как растаращить class-файл
Обычно при компиляции Java-файла получаются .class-файлы примерно того же размера, что и исходник. Меня заинтересовало, можно ли по небольшому исходнику сделать .class-файл, который больше, сильно больше исходника.Можно поискать какие-то короткие конструкции языка, которые компилируются в длинные цепочки байткода, но линейный прирост меня не устраивал. Я сразу подумал про компиляцию finally-блоков: про неё уже писали на Хабре. Если вкратце, то для каждого finally-блока при непустом try-блоке создаётся минимум два варианта в байткоде: для случая нормального завершения try-блока и для случая завершения с исключением. В последнем случае исключение сохраняется в новую локальную переменную, выполняется код finally, затем исключение достаётся из локальной переменной и перебрасывается. А что если внутри finally снова разместить try-finally и так далее? Результат превзошёл все ожидания.Я компилировал с помощью Oracle javac 1.7.0.60 и 1.8.0.25, результаты практически не отличались. Путь для исключения формируется даже в том случае, если в блоке try совсем ничего предосудительного. Например, присваивание целочисленной константы в локальную переменную — это две инструкции iconst и istore, ни про одну из них в спецификации не сказано, что они могут сгенерировать исключение. Так и будем писать:
class A {{ int a; try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { try {a=0;} finally { a=0; }}}}}}}}}}}} }} Добавление нового нетривиального кода в самый внутренний finally вызывает ошибку компиляции code too large, поэтому ограничимся таким. Если кто-то подзабыл, это у нас блок инициализации, который подклеивается к каждому конструктору. Для нашей задачи метод объявлять смысла нет.Такой исходник занимает 336 байт, а получившийся class-файл растаращило до 6 571 429 байт, то есть в 19 557 раз (назовём это коэффициентом растаращивания). Даже при отключении всей отладочной информации с помощью -g: none class-файл весит 6 522 221 байт, что ненамного меньше. Посмотрим, что внутри с помощью утилиты javap.
Пул констант
Пул констант получился небольшой: всего 16 записей. По сути всё самое необходимое: имена атрибутов типа Code, имя класса, Java-файла, ссылка на конструктор родительского класса Object и т. д. При отключении отладочной информации исчезают три записи: имена атрибутов LineNumberTable, SourceFile и значение A.java для атрибута SourceFile.Код
Код конструктора по умолчанию составил 64507 байт, почти упираясь в максимально допустимый предел. Начинается он с нормального выполнения: Код
0: aload_0
1: invokespecial #1 // Method java/lang/Object.»
iconst_1 — 8191 раз istore_1 — 8191 раз goto — 4095 раз athrow — 4095 раз astore_2/aload_2 — 1 раз astore_3/aload_3 — 1 раз astore/aload — 252 раза (локальные переменные с номерами от 4 до 255) astore_w/aload_w — 3841 раз (локальные переменные с номерами больше 255) Плюс один aload_0, один invokespecial и один return — итого 32765 инструкций. Желающие могут нарисовать граф потока управления и повесить на стенку.Таблица исключений Таблица исключений содержит записи вида (start_pc, end_pc, handler_pc, catch_type) и говорит виртуальной машине «если при выполнении инструкций от адреса start_pc до адреса end_pc произошло исключение типа catch_type, то передай управление на адрес handler_pc». В данном случае catch_type везде равен any, то есть исключения любого типа. Записей в таблице 8188 и занимает она примерно столько же, сколько и код — около 64 килобайт. Начало выглядит так: from to target type 26 28 33 any 24 26 41 any 42 44 49 any 49 51 49 any 22 24 61 any Таблица номеров строк Таблица номеров строк — это отладочная информация, сопоставляющая адресам инструкций байткода номера строк в исходнике. В ней 12288 записей и чаще всего попадаются ссылки на строчку с самым внутренним finally. Занимает она около 48 килобайт.StackMapTable Куда же ушло всё остальное место? Его заняла таблица StackMapTable, которая необходима для верификации class-файла. Если совсем грубо, для каждой точки ветвления в коде эта таблица содержит типы элементов в стеке и типы локальных переменных в данной точке. Так как локальных переменных у нас очень много и точек ветвления тоже, размер этой таблицы растёт квадратично от размера кода. Если бы локальные переменные для исключений в непересекающихся ветках переиспользовались, их бы потребовалось всего 13 и таблица StackMapTable была бы куда скромнее по размерам.Таращим дальше Можно ли растаращить class-файл ещё сильнее? Конечно, можно раскопировать метод, содержащий вложенные try-finally. Но компилятор вполне может сделать это за нас. Вспомните, что блок инициализации приклеивается к каждому конструктору автоматически. Достаточно добавить в код много пустых конструкторов с разными сигнатурами. Здесь будьте осторожны, а то у компилятора кончится память. Ну вот так можно скромненько написать, упаковав код в одну строчку: class A{{int a; try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{try{a=0;}finally{a=0;}}}}}}}}}}}}}A (){}A (int a){}A (char a){}A (double a){}A (float a){}A (long a){}A (short a){}A (boolean a){}A (String a){}A (Integer a){}A (Float a){}A (Short a){}A (Long a){}A (Double a){}A (Boolean a){}A (Character a){}} Здесь у меня 16 конструкторов, исходник занимает 430 байт. После компиляции имеем 104 450 071 байт, коэффициент растаращивания составил 242 907. И это не предел!
