Как “дублированный” код Java оптимизирован JIT-компилятором JVM?
Я отвечаю за поддержание базирующегося приложения JSP, работая на IBM WebSphere 6.1 (IBM J9 JVM). Все страницы JSP имеют помехи, включают ссылку, и в этом включают файл существуют некоторые статические объявленные методы Java. Они включены во все страницы JSP для предложения "легкого доступа" к тем служебным статическим методам. Я знаю, что это - очень плохой способ работать, и я работаю для изменения этого. Но, только для любопытства, и поддерживать мое усилие в изменении этого, я задаюсь вопросом, как эти "дублированные" статические методы оптимизированы JIT-компилятором JVM.
- Они оптимизированы, отдельно даже имея ту же самую подпись?
- JIT-компилятор JVM "видит", что эти методы все идентичны предоставление "объединенного" кода JIT'ed?
3 ответа
Каждая страница JSP компилируется в уникальный класс, и поэтому включаемый код также будет компилироваться в отдельные классы. JIT не будет объединять различные копии кода в один.
Чтобы избежать этого, вы можете поместить импортируемый код в настоящий класс Java и импортировать его в JSP. Тогда дубликатов не будет, поскольку вы повторно используете один и тот же класс.
Вы можете использовать статический импорт из одного класса: <% @ page import = "static foo. *"%>.
Тогда у вас больше не будет всего этого дублирования. И кроме импорта вам не нужно ничего трогать.
Ответ @mdma верен для текущих JVM, но требует уточнения в нескольких отношениях.
JIT в будущих JVM, возможно, могут поддерживать агрессивную оптимизацию для уменьшения объема памяти, занимаемого машинным кодом.
Обратной стороной является то, что, если у вас нет тысяч отдельных JSP, высока вероятность, что накладные расходы нескольких статических методов на каждый класс JSP не будут иметь большого значения для объема памяти вашего веб-приложения.