2010-06-17 4 views
7

Я отвечаю за поддержку приложения на основе JSP, работающего на IBM WebSphere 6.1 (IBM J9 JVM). На всех страницах JSP есть ссылка static include, и в этом файле include есть некоторые статические методы Java, объявленные. Они включены во все страницы JSP, чтобы предложить «легкий доступ» к этим статическим методам утилиты. Я знаю, что это очень плохой способ работать, и я работаю над этим. Но, просто для любопытства и для поддержки моих усилий по изменению этого, мне интересно, как эти «дублированные» статические методы оптимизируются JVM JIT-компилятором.Как «дублированный» Java-код оптимизирован JVM JIT-компилятором?

  • Они оптимизированы отдельно, даже имея точную подпись?
  • Компилятор JVM JIT «видит», что эти методы идентичны, и обеспечивает «унифицированный» JIT-код?
+0

Не могли бы вы освежить мой разум и сказать мне, что такое синтаксис для 'static include'? – OscarRyz

+1

Включает в себя директиву JSP (<% @ page include = "includeFile.inc"%>). Содержимое «includeFile.inc» статически включено в код JSP во время компиляции. Динамическое включение может быть выполнено с использованием тега JSP (), где вы можете ссылаться на URL-адрес, а контент включен во время выполнения. С помощью тега вы также можете выбрать статический include. –

+0

+1 для поддержки. Я был именно там, где ты сейчас. Единственное отличие в проекте, который я унаследовал, это то, что эти «статические» методы были вырезаны и вставляются в каждую страницу JSP. –

ответ

11

Каждая страница JSP скомпилирована в уникальный класс, поэтому включенный код также будет скомпилирован в разные классы. JIT не будет консолидировать различные копии кода в один.

Чтобы избежать этого, вы можете поместить импортированный код в настоящий Java-класс и импортировать его в JSP. Тогда дубликатов не будет, так как вы повторно используете один и тот же класс.

0

Вы можете использовать статический импорт из одного класса: <% @ page import = "static foo. *"%>.

Тогда у вас больше нет дублирования. И кроме импорта вам не нужно будет прикасаться к чему-то другому.

3

@ Ответ mdma правильный для текущих JVM, но должен быть квалифицирован в нескольких отношениях.

  1. JITs в будущих JVM могут поддерживать агрессивную оптимизацию для уменьшения объема памяти собственного кода.

  2. Flipside заключается в том, что, если у вас нет тысяч JSP-систем, вероятность того, что накладные расходы нескольких статических методов на класс JSP не будет иметь большого значения для объема памяти вашего веб-сервера.

 Смежные вопросы

  • Нет связанных вопросов^_^