Чому JIT не керує кодом JIT кеш?

Канонічна реалізація JVM від Sun застосовує деяку досить складну оптимізацію для байт-коду для отримання майже нативної швидкості виконання після того, як код був запущений кілька разів.

Питання в тому, чому цей компільований код, кешований на диску, не використовується для подальшого використання тієї ж функції / класу?

Як відомо, щоразу, коли програма виконується, компілятор JIT запускається знову, а не використовуючи попередньо складену версію коду. Чи не додавання цієї функції не додасть суттєвого імпульсу початковому часу запуску програми, коли байт-код по суті інтерпретується?

Не вдаючись до cut'n'paste посилання, яке розмістив @MYYN, я підозрюю, що це тому, що оптимізації, які виконує JVM, не є статичними, а досить динамічними, заснованими на шаблонах даних, а також на кодових моделях. Ймовірно, що ці шаблони даних зміняться протягом життя програми, що зробить кешовані оптимізації менш оптимальними.

Тож вам знадобиться механізм, щоб встановити, чи були збережені оптимізації все ще оптимальними, і тоді ви можете просто повторно оптимізувати на ходу.

JVM Oracle дійсно документально підтверджено для цього - цитуючи Oracle,

компілятор може скористатися моделлю роздільної здатності класу Oracle JVM, щоб додатково зберегти компільовані методи Java через дзвінки в базу даних, сеанси чи екземпляри. Така наполегливість дозволяє уникнути зайвих витрат непотрібних перекомпіляцій через сеанси чи випадки, коли відомо, що семантично код Java не змінився.

Я не знаю, чому всі складні реалізації VM не пропонують подібних варіантів.

Оновлений до існуючих відповідей - Java 8 має JEP, призначений для вирішення цього питання:

=> JEP 145: Складений кеш-код . Нове посилання .

На дуже високому рівні його заявлена мета :

Збережіть і повторно використовуйте скомпільований нативний код з попередніх запусків, щоб покращити час запуску великих програм Java.

Сподіваюся, це допомагає.

Excelsior JET має кешируючий JIT-компілятор з версії 2.0, випущений ще в 2001 році. Більше того, його компілятор AOT може перекомпілювати кеш-пам'ять в один об'єкт DLL / спільний доступ, використовуючи всі оптимізації.

Я не знаю справжніх причин, не беручи жодної участі у впровадженні СВМ, але я можу придумати деякі правдоподібні:

• Ідея Java - це бути мовою, що записується коли-небудь, і введення попередньо складених матеріалів у файл класу є таким чином, що це порушує (лише "вид", оскільки, звичайно, фактичний байт-код все ще буде)
• Це збільшило б розміри файлів класу, тому що ви мали б один і той же код там кілька разів, особливо якщо вам трапляється запускати одну і ту ж програму під декількома різними JVM (що насправді не рідкість, коли ви вважаєте різні версії різними JVM, які ви справді треба робити)
• Файли класів самі по собі можуть бути недоступними для запису (хоча це було б досить легко перевірити)
• Оптимізації JVM частково базуються на інформації про час виконання, а в інших програмах вони можуть бути непридатними (хоча вони все-таки повинні забезпечити певну користь)

Але я справді здогадуюсь, і як ви бачите, я не думаю, що будь-яка з моїх причин - це фактичні зупинки шоу. Я вважаю, що Sun просто не вважає цю підтримку пріоритетною, і, можливо, моя перша причина близька до істини, оскільки це звичайно може також привести людей до думки, що файли класу Java справді потребують окремої версії для кожного віртуального комп'ютера, а не крос-платформа.

Мій кращий спосіб насправді полягав би в тому, щоб мати окремий перекладач байт-коду до рідного, який ви могли використовувати заздалегідь, щоб зробити щось подібне, явно створюючи файли класів, які явно побудовані для певного VM, можливо, оригінальний байт-код у них, щоб ви може працювати також і з різними віртуальними машинами. Але це, мабуть, випливає з мого досвіду: я в основному займався Java ME, де дуже боляче, що компілятор Java не спритніший щодо компіляції.